Menu
Community /Pin to ProfileBookmark
Though that goes with who HTML 5's target audience seems to be; all the people who never extracted their craniums from 1997's rectum, and continue to this day to sleaze out HTML 3.2 or the proprietary garbage that was never part of the specification [i]How exactly do you deprecate something that was never part of the specification anyways?!?[/i] -- and until recently were slapping 4 tranny on it. Now they slap the 5 lip-service doctype around the same outdated, outmoded code and slap each-other on the back over how "modern" they are.
I would suggest working one step at a time, since "progressive enhancement" -- adding technologies one at a time to a complete site -- is the core of how one should build a site anyways. You learn to use HTML properly, then you learn to use CSS, then you learn JS -- start out with a static site, then dive into something like PHP to make it 'dynamic' and to make it easier to maintain, then dive into SQL for tracking large amounts of data efficiently.
Now, when I say use HTML properly, I mean "semantic markup" and "separation of presentation from content". They both actually mean the same thing, using the HTML tags for what they MEAN, [b]NOT WHAT THEY LOOK LIKE!!![/b] -- generally speaking in all but the rarest of cases, you have no business saying in your HTML what things should look like; be it your choice of tags, the classes and id's you put on those tags, whatever... does not belong there.
Assuming you at least know how to open and close tags, it's just a matter of learning what they mean. I like this older reference for it's clarity and simplicity:
http://htmlhelp.com/reference/html40/
Go through and learn the tags, pay particular attention to the description of the tag's MEANING, as well as what 'level' the tag is (block or inline) as well as "contents" and "contained in" which give you the rules of what tags can go where.
For example, take UL:
http://htmlhelp.com/reference/html40/lists/ul.html
It's not actually block or inline, though it's default behavior is display:block; -- it can be contained only in the tags listed, aka those are the only tags that can be it's direct 'parent', and the ONLY direct child it can have is a LI... which is why this:
<ul><h2>Some text</h2><li>First item</li></ul>
is gibberish, H2 can't be a child of a UL... though it COULD be the grandchild as a child of LI.
Go through and READ ALL THE TAGS. Also pay attention to which ones are 'non-strict' or just tick the button to hide non-strict, as those tags and attributes HAVE NO BUSINESS BEING USED ON WEBSITES WRITTEN AFTER 1997.
One bit that people don't get and is hard to glean from the specification or any online reference is how to use numbered headings -- they are really simple if you know professional writing, but since most people making HTML these days are barely literate TLDR nitwits who can barely make big enough a coherent thought to fill a tweet, it's not a shock few people grasp the concept. I'll outline it quick.
Lower ordered (higher numbered) headings mean the start of a subsection of the higher order (lower numbered) heading preceeding it. Using a H2 means you are starting a subsection of the H1 before it. Using a H3 means you are starting a subsection of the H2 before it... an so forth down to H6. This is why just blindly using H5 or H6 with no H4, H3 or H2 before them is gibberish. At the top is the H1 -- the heading under which EVERYTHING on the page is a subsection. That's why the H1 is best used as the site title or similar. Think of a newspaper -- what's at the top of EVERY page? The title of the paper (and usually the date) -- that's the H1. Sure, it's bigger on the front page, but in terms of structural importance [i](as opposed to important importance -- there's a difference and people screw that up reading the specification's legalese every time)[/i] they're all H1... Some people would say "what about the headline, that's the biggest text on the front page" -- and? STRUCTURALLY you aren't saying that "Woman found dead on Maple Ave" and "K-6 get new building" are subsections of "[b]MAYOR CAUGHT TAKING BILLION DOLLAR BRIBE[/b]" -- they're all H2, siblings to each-other and subsections of the paper. [i]Either that or you're in one really screwed up town.[/i]. Likewise there's "horizontal rule" -- which people seem to think means "draw a line across the page" -- while that's the default appearance, in professional writing you'd use a horizontal rule to indicate a change in topic where a heading is unwanted or unwarranted. So it is in professional writing, so shall it be in HTML.
[i]...and when you get into HTML 5 you'll find they pissed all over this with the pointlessly redundant SECTION, NAV, ARTICLE and FOOTER tags[/i]
Many of the tags that have semantic meanings thanks to their being used as a markup specification people THINK are presentational, when they are not. B and I (bold and Italic) for example do NOT mean "this text must be shown as bold and italic" because when TBL made HTML not every device was even capable of showing bold and italic. They mean "would be bold or italic in a properly written document" -- which is to say for things like proper names, books, etc... you'll often hear ignorant halfwits saying "use STRONG and EM instead" or worse, "B and I are deprecated" -- the former is often bad advice, the latter is 100% grade A farm fresh bull. EM and STRONG mean "emphasis" and "with more emphasis" respectively -- you aren't emphasizing the title of a book, you aren't adding more emphasis just because you mention the name of a company. B and I's semantic meaning of "would be bold or italic in a professionally written document" still has it's place.
more than anything, when you start making a page you should start with what you want on the page in plaintext or IMG links (and I mean content images, not images as text crap like some incompetent fools do with menu buttons and the like); that's your content. Just put it -- or at the very least a reasonable facsimile of future content -- into a normal flat text editor and arrange it into an order that makes sense as if HTML never even existed.
You then go through and add your semantic tags to say what things are... Your headings to break it into sections so you have a logical document structure, A (anchor) around your links, menus being lists of choices get lists, bullet point lists get lists, paragraphs around your actual grammatical paragraphs -- keeping in mind a lone image is NOT a grammatical paragraph, a sentence fragment in the middle of nowhere is NOT a paragraph. These large blocks of text in this post separated by periods and spaces into sentences? THAT'S A BLOODY PARAGRAPH. (It's often shocking where people just throw paragraph and to hell with it's meaning).
This gives you a semantic baseline... which means search engines, screen readers, braille readers, and people who block fancier bits of tech because their connection or bandwidth sucks will have a useful, if rather plain page. That's the first step in what is commonly called "accessibility".
THEN and ONLY THEN do you start worrying about the page's appearance, and that's the job of CSS, sometimes with a bit of assistance from the two semantically neutral tags "DIV" and "SPAN", which are 'block-level' and 'inline-level' respectively. You should at least TRY to style as much as possible without adding extra tags, but at this point you probably will end up adding a good number of DIV and even a few SPAN. Those tags exist to group elements together for styling WITHOUT saying what that style IS...
[i]Which is why HTML 5's SECTION, NAV and FOOTER are also silly, you shouldn't be using tags with "meanings" redundant to existing tags with meanings you should already have on the page just as styling hooks.[/i]
.... to be continued (10k post limit is really annoying guys!)
When it comes to making your CSS Layout[b]S[/b] -- you need to remember to keep that plural. With the plethora of device capabilities, default font rendering sizes (on which your layout should be based, none of that pixel measurement garbage), screen resolutions and PPI, you are best off making layouts that are semi-fluid (expand and contract to fit with a upper-limit set by max-width), elastic (fonts and layout auto-expands/contracts based on the default font size) and responsive. (The new kid, and the next logical step in accessible design, changing the layout based on the available screen space).
CSS is the hard part... that's gonna take you a while to learn... but the core of it is that HTML is for saying what things ARE, CSS is for saying what they look like... on specific targets.
Then and ONLY then do you start thinking about dicking around in Photoshop or some other paint program to make the graphics you hang on the layout (if any, thanks CSS3!!!), Then and ONLY then should you enhance the page with JavaScript.
There's an ... unwritten rule to JavaScript "If you can't make the page work without scripting FIRST, you likely have no business adding JavaScript to it!" -- but really that applies across the board to EVERY client side enhancement you make to a page and it's content. JavaScript, CSS, HTML -- if any of those are missing, is the page still at least delivering the content? That first and foremost is the goal, and the reason HTML even exists, CSS even exists, and why you "progressively enhance" the page -- with HTML, with CSS, with presentational images, with scripting -- so if any of those along the way fail, are unavailable, or are intentionally blocked, the page "gracefully degrades" while remaining usable.
... a concept lost on a lot of the PSD Jockeys and Script-tards out there; who piss out flashy and very pretty pages, that are ultimately useless to large numbers of users as they drool all over the place and when pressed go "Accessibility, what's that?" or worse "Who gives a ****?" -- great plowing attitude right there.
I would also suggest you at least TRY to read the WCAG -- web content accessibility guidelines:
http://www.w3.org/WAI/intro/wcag
But beware like every other W3C specification it's written in hard to decipher legalese; be familiar with it, but really there are three major points that stand out above everything else once you hit the design stage...
1) Elastic/Dynamic fonts -- Avoid declaring fonts in pixels unless you absolutely have to (like an image background interaction on a button). They are inaccessible crap for large font/120dpi users like myself, sending us diving for the zoom. There is more to web design than the default font and pixels per inch you happen to be seated in front of.
2) Fluid or semi-fluid layout -- Avoid fixed width design, it will piss somebody off somewhere at some time, particularly when combined with the first of these little screwups since if you dive for the zoom and end up stuck side-scrolling, you're REALLY going to piss people off.
3) Legible colour contrasts -- Certain colour combinations are illegible. Don't use them. There's math for checking background vs. foreground colours; I've gone over that in so many posts lately... I'll just post a link to a recent one:
http://www.webdeveloper.com/forum/showthread.php?295739-Review-my-website&p=1337785#post1337785
Middle of that post I outline the formula, which is pretty much what the WCAG recommends, and can also be found in a joint usability study by Apple, IBM and M$ that worked it's way into the UI design guidelines for all three companies, as well as the VGA specification itself.
Sad part being most people making UI's and talking about UX (user experience) have thrown that in the trash, and don't know the first thing about usability -- and instead are using the term UX to justify their sleazy, bloated, slow loading and ultimately useless trash like some sort of lame excuse.
Which I also recommend reading this article, so you can recognize the lame excuses when you encounter them:
http://www.456bereastreet.com/archive/200704/lame_excuses_for_not_being_a_web_professional/
Oh, and one other thing, comments; good commenting is good coding, pointless and bad commenting is worse than having none at all. Even though it's meant for C programmers, I think anyone writing code be it actual programs or markup/stylesheets can benefit from this article:
http://www.ibm.com/developerworks/library/l-clear-code/
I'm particularly fond of the "oh, now we're done" part as you'll often see that scale of ineptitude in HTML.
<!-- start content -->
<div id="content">
No, REALLY? A DIV with the ID "content" on it is the start of the CONTENT? Whoddathunkit?!?
Also beware that comments -- yes, COMMENTS, the part browsers are supposed to ignore -- can trip rendering bugs in some versions of IE and FF. No joke... IF they end up between sibling elements that are floated or recieve positioning they can randomly trip either the 'double render' bug or 'disappearing content' bug -- which their names say EXACTLY what they do.
So a nice trick to avoid that, don't use idiotic opening comments like above, and if you want a closing comment instead of:
</div><!-- end content -->
Move it inside the close (and don't say "end", that's what </div> already means!)
<!-- #content --></div>
Notice I use the # to say it's an ID being closed. Because it's inside the close it can never be between sibling elements, dodging that particular annoying bullet I've seen people waste massive amounts of hacks and extra elements to try and sneak past.
Ok, I'm starting to ramble, but hopefully you can extract some useful bits from between my hating on HTML 5 and insulting the mental faculties of most of the people calling themselves "designers" who don't know enough HTML, CSS or accessibility to be designing but two things -- and Jack left town. ?
@NogDogJun 13.2014 — #Partly you may first want to decide what your professional goal is. There is always a need for good graphic designers who can use Photoshop and related tools to do all the visual design stuff. To be really marketable in the web business, it would be very helpful to have a good grasp of HTML and CSS, and how to use them correctly.
If you want to get into the full front-end development thing, then you'll have to know JavaScript (which has virtually nothing to do with Java, by the way) in order to do all the fancy user experience things everyone feels they must have these days.
If you want to be a one-person web shop/freelancer, though, then you start talking about server-side programming and databases, which is a whole 'nother package of skills (and maybe mindset?). I'm personally more interested in and better at the server-side stuff and that's what I specialize in at my current job (besides which my artistic skills are pretty much at the level of "I know a good design when I see one, but I don't know how to get there from scratch").
... especially if you can learn to stay the blue blazes away from goofy crap like scripttard animations for nothing, JS that replaces HTML functionality, massive background images that have no business on websites in the first place, and all the other "designer" nonsense that does nothing but get in the way of doing what's actually important on a website.
Delivering CONTENT to users in as accessible and speedy a manner as possible; because at the end of the day people do NOT visit websites for the flashy graphics or goofball animated garbage you hang around the content, they visit FOR the content.
Which is why some of the BEST web designs are the one you'd never actually go "hey, cool design" -- because if you notice the design before you notice the content, there's something wrong with the design... or the content! [i](or in most cases, BOTH!)[/i]
Just look at the big success stories of the Internet -- Google, facebook, twitter, Amazon, eBay -- not exactly a visual tour-de-force that makes you think someone sat there for hours playing around in Photoshop, are they? Even when they are an inaccessible poorly coded mess, their design is simple and content oriented -- because they know what's important. Delivering their content to visitors like you and I.@NogDogJun 13.2014 — #Yeah, if you have "heroin content", you don't need shiny objects to attract people to it. ? (And I've been driven away from more than a few web sites without ever sampling their content due to the headaches instilled by all their shiny objects. ? )
Deathshadows comments seem to be based on the idea that fonts declared in pixels are fixed to the respective size. Whereas fonts in EMs can auto-scale to different pixel sizes in response to the default font size set in Windows or Linux. Sounds a great idea? However, the reality, as I understand it, is somewhat different:
So, it seems that there is little [i]practical[/i] benefit in declaring fonts in EMs. Furthermore, manually zooming the display is not the only alternative. As I understand it all the major browsers allow you to set a default zoom level, which scales graphics as well as text. It does not care whether settings are in EMs or PXs, and is not linked to the OS setting.
Furthermore, there is at least one good reason why linking the default zoom of text (or graphics) to settings in the OS is not a good idea: It's a real pain to test. This is because changing the default font size in the OS, (to see whether the browser responds) gratuitously rearranges the icons on the desk top. Ouch!
Two good reasons -- first browser scaling of images looks like ass... and not hot juicy playboy ass, but don't wear that thong cottage cheese ass. Second, enlarging template images would consume screen space better used for delivering what's actually important -- CONTENT!
Excepting of course Firefox and Chrome... which do... and I had thought Safari supported it too ; but I can't test that right now as I no longer have a working OSX install here - one of the things I need to fix.
Excepting Opera... and Blazer... and whatever the **** RIM is using right now...
...and the version of Chrome that comes with most Android devices. Settings > Accessibility > text-scaling
You mean Chrome, Opera, ICEWeasel, Konqueror and Firefox are "obsolete" browsers? REALLY?
You can set it manually in the settings of ALL those browsers...
Chrome:
http://www.cutcodedown.com/images/Chrome_defaultFontSize.jpg
Firefox: (you MAY have to go into :config to change a value on windows if large fonts is OS enabled)
http://www.cutcodedown.com/images/FF_defaultFontSize.jpg
ChrOpera: (aka the pathetic crippleware Opera)
http://www.cutcodedown.com/images/ChrOpera_defaultFontSize.jpg
Opera 12.x:
http://www.cutcodedown.com/images/Opera12_defaultFontSize.jpg
In the webkit browsers the choices in that dropdown are: medium == 16px, large = 20px, X-Large == 24px as the default size. Not sure what the smaller sizes are, but they are likely 12px and 8px. (not that I could ever see anyone choosing 8px)
Except you can also set it IN THE BROWSER separate from the values above. I usually have Opera 12 (my primary browser), ChrOpera and FF locked into the large font behavior, and Chrome/IE not. It can be inherited from the OS (in OS that actually care about users like Windows), [b]or[/b] you can set it manually.
We were talking about this via PM last week, and I'm not understanding why you seem to be having so much trouble finding such an easy to use (and commonly used) setting... It's almost like you just don't want it to be true or something.
To people with impaired vision? I doubt it.
"Better used for content" is a subjective view, not a matter of fact. Designers use template images, and size them to suit the overall aesthetic of the design. Do some designers overuse graphics? Yes. Does that invalidate all use of template images? No.
PRECISELY!!! The settings are in the browser, NOT inherited from the OS.
But Windows 7 and 8 do not suppport the setting of the default font size without also scaling images.
On the contrary, I was much impressed by your exposition of the benefits of using EMs, right until you said:
You may feel otherwise, on principle, but based on your own comments, surely any person who does not already use EMs would conclude that there is little [i]practical[/i] benefit in using them??? Also I am yet to be convinced that this is a valid [i]accessibility[/i] issue. Some users, like yourself, [i]choose[/i] to set different font sizes without resizing images but that is a matter of preference, not accessibility. Should something as fundamental as the use of EMs rather than PXs be based on the preferences of a small number of users?
Not everyone who uses it has impaired vision; many of us do so to avoid jaggies or just because their displays have higher PPI and they don't feel like keeping their nose plastered an inch from the display.
When I first started using the setting TWENTY-FOUR years ago on Windows 3.0, most people were running 640x480 on 14" CRT's... we didn't have font smoothing, and the jaggies on some fonts were absolutely dreadful; running 800x600 or 1024x768 at 8514/large fonts reduced the jaggies by introducing more PPI.
Today my workstation runs 2560x1440 at 27" -- which in reality works out to many more pixels per inch than a 24" 1920x1200 -- which works out to many more pixels than the typical el-cheapo 21" 1440x1024 -- and now we have 1920x1080 21" displays -- and my 17" laptop is also 1920x1080...
... and lately, to be frank, I'm worried about back strain in others watching the way they hunker over their laptops or across the desktop screen. It's actually more scary than the allegedly ergonomic garbage of the early '90's that was more placebo than fact.
I still have no clue what you mean by that -- unless you're talking about the auto-swap internal of ICO's on supported one and enlarging of ones that don't have the MPF (multiple pixel format) version of WMF (windows metafile format)... though admittedly, developers who don't make applications for Windows seem blissfully unaware that ICO files can store multiple resolutions of the same image from 16x16 to 256x256; in multiple colour depths.
But what that has to do with image scaling is beyond me... since if I open a image in PSP, Photoshop or Paint it isn't auto-zoomed. I open image in irfanview it's not auto-zoomed... I open a word document or PDF the behavior is no different... and if I have the browser set to the behavior we're talking about... well, do I have to say it?
I'm sorry, but to me that's the "just because some people don't use it nobody needs it" attitude -- JUST because java swing crapplets, QT and GTK don't support it [i]by default[/i], doesn't mean ALL THOSE ONES I LISTED THAT DO -- including 90%+ of windows applications -- don't... and you can be pretty well guaranteed the people who 'need' or just use it (and there's a difference) are going to use applications that don't... and that's the message. Don't alienate potential users.
ESPECIALLY when anything built with Metro or the Win32 api do support it -- that's only what, 95% of desktop applications?
Though it does seem a LOT of things now have the "only a few people use it, so who needs it" attitude; see the pathetic crippleware known as ChrOpera that removed everything making Opera worth using over other browsers -- or the repeated dumbing down of OS UI with the likes of Windows 8, Gnome 3, and OSX that are more concerned with being new for new's sake, and who cares about lost functionality.
It's really starting to piss me off across the board on just about everything computer related -- you figure in the halfwit garbage of sleazy shortcuts for EVERY level of development, and dialing the clock back to the worst of late '90's coding practices that is the steaming pile of manure known as HTML 5...
[i]If this is the future, I think I'll pass.[/i]@NogDogJun 16.2014 — #I have impaired vision -- not legally blind type, but debris in one eye from a torn retina as well as a macular pucker (on top of being pretty near-sighted). When I have to hit Ctrl-+ a couple/three times to make a web page legible, and some non-essential graphic (i.e. decoration, not content) starts taking up more screen space, it can be a pain in the ass, depending on how the page is laid out. If I set a minimum font size in the browser preferences, you'd be amazed (or maybe not?) how many web site designs break to some degree as a result.
Unfortunately, lots of web pages are designed and implemented by 20-somethings with youthful eyes, who for some reason feel their designs look better with 8-point Helvetica in some shade of medium-dark gray, and who don't test them to play nicely with people like me. :rolleyes: (If you stop by our office, I'm the guy with his monitors no more than a foot away from his nose, using a larger font in his code editor than any of the other developers. ? )
I'm actually legally blind now, but that's because I can't read street signs more than 15 feet away, inside that distance I'm as if not better sighted than most people; much of that being my larger field of view and lack of tunnel vision regardless of what I'm doing.
In my case it comes from a dislocation of my right eye from explosive decompression some 14 years ago. Fun stuff.
Or if you DARE to actually use the zoom.
... and that's WHY I advocate all the design and development practices I do -- if you make the page elastic, it will auto-adjust to the users font size choices. If you make it fluid (or semi-fluid) it will adjust to the available space, but the layout will ALSO adjust when you zoom, preventing it from breaking. Likewise the new kid -- responsive layout -- can be set to re-arrange the layout to fit the available space, and that too supports not just the elastic fonts, but zooming as well.
It's also the origin of the "trifecta of /FAIL/" at web design: Fixed width layouts, px metric fonts, illegible colour contrasts. All three amount to the same failing, making it harder for users to get at what's important -- the content.
Take fixed width layouts for example: They are either 'crappy little stripes' on big displays, or broken and useless on smaller ones; Whenever people ask "what width should I design to" I [b]KNOW[/b] they have either been led down the garden path by someone who doesn't know enough to be telling them how to build a site, or are SO deeply ingrained in 'what things look like' in front of them, they cannot grasp that what's in front of them isn't what everyone has. See the lame "800px friendly" of the previous decade, and the "1024 friendly" crowd of today -- all of whom missed the boat the moment mobile came along and pissed all over that with sizes ranging from 192px wide to 1080p tablets.
There have ALWAYS been the lame excuses people come up with to justify their even lamer development practices -- oh this is only x% of users... Oh everyone has broadband now... Everyone is using multi-ghz processors with multi-gigs of RAM... and to be frank, I've been hearing that crap for FIFTEEN YEARS and every single time it's been one big fat steaming load trashed by "the next big thing".
If you build elastic, semi-fluid AND responsive, you have pretty well covered the bases -- meaning the number of places it CAN break are eliminated. It's not rocket science, it's not hard... people MAKE it hard. They make it hard by not bothering to learn how to use HTML 'properly' (aka semantic markup), not bothering to use all the good practices like progressive enhancement and graceful degradation, and so forth.
See why there are certain design concepts -- like multiple equal-height, equal-width containers across a page, "rotators" / "Banner animations" with paragraphs of text inside them, and so forth, IMHO have no place on a site design if you care about accessibility... or should I say "Visitors actually WANTING to use your website". But then there's a reason to me things like that -- along with the artsy fartsy picture heavy themes, and goofy JS for nothing animations people use -- amount to little more than sweeping under the rug a lack of content, or worse developer incompetence.
In many ways, a well written website should be... well, a certain martial artist put if fairly well:
[i]"You must be shapeless, formless, like water. When you pour water in a cup, it becomes the cup. When you pour water in a bottle, it becomes the bottle. When you pour water in a teapot, it becomes the teapot. Water can drip and it can crash. Become like water my friend.”[/i] -- Bruce Lee
You load a well written website on a phone, it becomes the phone. You load it on a tablet, it becomes the tablet. You load it on a desktop, it becomes the desktop.
Of course, that 90% of the tutorials online and 95%+ of the books on shelves are 1997 scale web rot written by people who never learned to use HTML 4 properly certainly doesn't help... much less the dreadfully confusing legalese used in making the W3C specifications; when simple words like "empty" and "important" don't mean what normal people use those words for; how confusing must it be when words not used outside of courtrooms like "deprecated" or "normative" are in the mix?
I mean I can grasp the specification after YEARS of studying it, but when <div></div> is not what they mean by an "empty" element and <h1> doesn't mean "more important" than a <h2> in terms of importance on the page, but import to document structure (two entirely different things) I can't help but wanting to knee-jerk into doing a Samuel L. Jackson impersonation, getting medieval on people's rumps with "Englisc, mōdor wyrter! Gedōn ēow cweþan hit!?!"
Actually you want a laugh, I'll see if I can find the study. There was some research done that showed that older developers were usually MORE likely to use smaller fonts... which struck me as odd since I always thought it was the other way around too.
Hmm. Striking out on finding it, it was three or four years ago, but my google-fu fails me.
My points are:
a) I do not agree that, as an [i]accessibility feature for partially sighted people[/i], that it is necessary, or even beneficial, to SEPARATELY set the default font size as opposed to zooming the display (whether set in the OS or browser).
b) Linking the setting (default font or zoom) to the OS is unnecessary and a pain in the butt to test, as resetting the default font or zoom trashes the icon positioning on the OS desktop.
Now, turning to your points:
Then zoom the display. This does not necessarily lead to "jaggies". E.g. At 125% on a 120ppi a 96px x 96px image is the same size as on a 96ppi display set at 100%.
Funny, my recollections are somewhat different. Compared to the 320 x 200 CGA displays I was used to, 640 x 480 VGA was wonderfully smooth (and had a 1:1 aspect ratio). The smoothness was probably helped by the limited resolution of the color CRT screens of the day. Jaggies on VGA screens only became noticeable (to me) when I purchased a Sharp laptop with a back-lit monochrome LCD display. However as the jaggies were a hardware feature, software scaling of fonts and/or images would have had no beneficial effect anyway.
Like I said, they can always zoom the display instead (dynamically or by resetting the default zoom).
I mean that Win 7 and 8 only support zoom scaling of the desktop.
So why should web browsers treat EMs different to PXs?
Like I said, in 7 and 8, (at least in the 64 bit versions I have access to) that functionality appears to have been dropped, at least so far as the OS is concerned.
I have given the reasons why I conclude that there is little [i]practical[/i] benefit in using EMs instead of PXs. I also question its validity as an [i]accessibility[/i] feature anyway. It seems to me that nothing you have said changes either of those views.
No, that's only HALF of it, as you can set it in the browser independant of the OS as well! Sure good browsers notice it by default, [b]but that does not mean you can't change it to your own custom choice in the browser as well! HENCE ALL THOSE SCREENCAPS I POSTED!?!?!?!?!?!?![/b]
Which.. it isn't absent... at all... no idea what you're even on about. Hell, they made it easier to get to and added more options! Unless they did something stupid to Home/Basic or something (neither of which I have)
Well, that's great for you -- but see NogDog's post? Again "I don't need it so **** everyone else" is not a great attitude for web development!
EXCEPT YOU CAN ALSO MANUALLY SET IT!!! [b]IN EVERY BROWSER![/b] [i]I even just tested, and it's in Safari on OSX too so...[/i]
Uhm... no... I zoom 125% regardless of ppi it goes all *ugly as sin. Zoom is often NOT a desired behavior -- more so when some idiot slaps things into a fixed width layout.
With raster fonts sure, you started showing truetype it looked like ass. Honestly CGA raster fonts at 640x200 were often more legible than truetype or postscript was at 640x480... but at that time we were dealing with truetype and postscript because desktop publishing was "The big thing" of the time. [i]and why I HATED dealing with it on the mac with it's fixed 72dpi displays![/i] -- scaleable fonts were the future, but the hardware really hadn't caught up yet.
Because it's a different measurement with a different meaning? Because moving forward PPI is going to climb? (what with 4k displays now coming in 29" and smaller flavors?) -- though what that question has to do with what you quoted is beyond me; I'm wondering if you comprehended what I said at ALL.
Which you must be doing something wrong or changing the wrong setting, or have ticked the wrong box. It behaves here for me in Win7 JUST like it has since nineteen-freaking-eighty-nine when it was called "8514 fonts".
Type this into explorer's (windows explorer, not IE) address bar:
Control PanelAll Control Panel ItemsDisplay
Which [b]should[/b] be the default page you get going to display from the control panel, or from 'personalize' [i](bottom left corner on the latter)[/i]. It's the first bloody page -- has the title "Make it easier to read what's on your screen"?
Small, Medium, Large, X-Large... corresponding to 16px, 20px, 24px and 28px... They've just given us more options on it than the original Small (16px) and Large (20px).
Are you using the goofy DPI setting thing that was introduced in win98 and NEVER worked right or something? The one under "set custom size"? Because THAT's unreliable and NOT the setting we're talking about. That's actually a vestigial leftover from sharing code with winCE/mobile... kind of like some of the useless broken stuff seeping in at the corners into Safari -- like it's broken implementation of the -webkit-text-resize property. [i]Which if used breaks desktop zooming, but not mobile zooming!?![/i]
Though that one is handy when setting up a system for ten foot operation.
Then you're either blind to it working, or doing it wrong. Though you seem to claim it doesn't exist and/or doesn't work on PLATFORMS I USE IT ON DAILY... So I really think you're either setting the wrong things, or being deliberately obtuse about it.
There's a reason the WCAG says to do it, there's a reason [b]it is in fact supported in every browser as a in-browser setting[/b], there's a reason it's in windows from Win 3.0 right through to 8.1... Gnome and KDE both have a degree of support for it too, and while it's not inherited by browsers on *nix platforms, [b]AGAIN IT EXISTS AS A OPTION YOU CAN MANUALLY SET IN EVERY BROWSER![/b]
Making me wonder just what the blue blazes you are on about with it allegedly "no longer existing"... since to be brutally frank, that's 100% grade A farm fresh horse dung. IT'S RIGHT FREAKING THERE!!! (lord knows I've given you the instructions enough blasted times by now!)
... and again, just because YOU "don't need it" or can't figure out how to use it, doesn't mean those of us who do use it and rely on it should be given a kick in the crotch by what is -- to be brutally frank -- the train wreck of developer ineptitude that is declaring font sizes in pixels and widths of flow content areas in pixels.
Sorry, but... damn... Herpafreakingderp buddy...Manchester escort agency website. Im struugling to get good quality sites, any advice on where to look?
Hitting a Wall
So I’v been doing graphic design, mostly photoshop for about 8 years or so and general illustration since I can remember. Towards the end of high school I learned how to use Dreamweaver (barely) and a friend and I started making websites for local businesses. They were pretty much just a bunch of photoshop slices put together with some rollover images and a contact form thrown on a server. I mean, hey they worked and they looked okay. They were static sites so there was a lot less fuss, just the basics: a few pages (home, about, services, contact etc.) with text and maybe a flash slideshow Id put together as a banner here or there.
I just graduated from SUNY Albany with a degree in Environmental Science but with all the green talk and all the statistics I kept hearing about the growth of the field in general (Photovoltaics, sustainability blah blah blah) the job market SUCKS. Like really ****ing sucks. So iv been considering going back to what I know and love most, computers and graphic design.
So heres where the problem comes in, I want to be a real web developer not a WYSIWYG guy (which from poking around seems to be a harsh insult) and really learn code. First of all I think I should learn HTML5. I know how HTML works and everything (how colors work, tags and what not) but I have no idea how to legit use it to design a site.
But beyond that Im lost. Do I learn PHP which seems really cool since its also a programming language from what I gather and if youre coding in PHP it can read HTML and CSS mixed in right? So I looked at getting “Zend Certified”, that means I have to learn Zend framework for PHP, but I wanted to use XAMPP since it does everything for you, in terms of installing what you need for a workstation.
Then I hear all this stuff about “real coders” or “real web devs” who just use code, images, and a browser. That seems insanely hard.
Right now Im using Adobe Muse (which is ****ing awesome btw, at least I think) in tandem with PS and Edge for animations.
Is there anything wrong with doing it my way, with the Adobe suite? Its just a more artist, design driven way of doing things for me.
So basically Im totally lost…..Learning any language is a task and a half so what do I shoot for? CSS, HTML, PHP, XML (dont even know what that really is yet)… god damn theres a lot
P.S. – I have learned some java stuff before so I know calling classes (program in a program kinda thing), loops, arrays, **** like that I just
Sign in
to post a comment15 Comments(s) ↴
0
@deathshadowJun 13.2014 — #First I would suggest you properly learn HTML 4.01 STRICT and/or XHTML 1.0 STRICT (same basic thing, just some minor syntax differences) -- as they are the current RECOMMENDATION doctypes. Once you have that you can add the HTML 5 garbage if you want, but if you learn to use STRICT properly, you'll find out that 95%+ of HTML 5 -- so far as actually writing HTML -- just re-introduces redundancies STRICT was trying to get rid of, introduces all new redundancies, and through the loosening of structural rules seems bound and determined to roll back coding practices to the worst of the late browser wars.Though that goes with who HTML 5's target audience seems to be; all the people who never extracted their craniums from 1997's rectum, and continue to this day to sleaze out HTML 3.2 or the proprietary garbage that was never part of the specification [i]How exactly do you deprecate something that was never part of the specification anyways?!?[/i] -- and until recently were slapping 4 tranny on it. Now they slap the 5 lip-service doctype around the same outdated, outmoded code and slap each-other on the back over how "modern" they are.
I would suggest working one step at a time, since "progressive enhancement" -- adding technologies one at a time to a complete site -- is the core of how one should build a site anyways. You learn to use HTML properly, then you learn to use CSS, then you learn JS -- start out with a static site, then dive into something like PHP to make it 'dynamic' and to make it easier to maintain, then dive into SQL for tracking large amounts of data efficiently.
Now, when I say use HTML properly, I mean "semantic markup" and "separation of presentation from content". They both actually mean the same thing, using the HTML tags for what they MEAN, [b]NOT WHAT THEY LOOK LIKE!!![/b] -- generally speaking in all but the rarest of cases, you have no business saying in your HTML what things should look like; be it your choice of tags, the classes and id's you put on those tags, whatever... does not belong there.
Assuming you at least know how to open and close tags, it's just a matter of learning what they mean. I like this older reference for it's clarity and simplicity:
Go through and learn the tags, pay particular attention to the description of the tag's MEANING, as well as what 'level' the tag is (block or inline) as well as "contents" and "contained in" which give you the rules of what tags can go where.
For example, take UL:
It's not actually block or inline, though it's default behavior is display:block; -- it can be contained only in the tags listed, aka those are the only tags that can be it's direct 'parent', and the ONLY direct child it can have is a LI... which is why this:
<ul><h2>Some text</h2><li>First item</li></ul>
is gibberish, H2 can't be a child of a UL... though it COULD be the grandchild as a child of LI.
Go through and READ ALL THE TAGS. Also pay attention to which ones are 'non-strict' or just tick the button to hide non-strict, as those tags and attributes HAVE NO BUSINESS BEING USED ON WEBSITES WRITTEN AFTER 1997.
One bit that people don't get and is hard to glean from the specification or any online reference is how to use numbered headings -- they are really simple if you know professional writing, but since most people making HTML these days are barely literate TLDR nitwits who can barely make big enough a coherent thought to fill a tweet, it's not a shock few people grasp the concept. I'll outline it quick.
Lower ordered (higher numbered) headings mean the start of a subsection of the higher order (lower numbered) heading preceeding it. Using a H2 means you are starting a subsection of the H1 before it. Using a H3 means you are starting a subsection of the H2 before it... an so forth down to H6. This is why just blindly using H5 or H6 with no H4, H3 or H2 before them is gibberish. At the top is the H1 -- the heading under which EVERYTHING on the page is a subsection. That's why the H1 is best used as the site title or similar. Think of a newspaper -- what's at the top of EVERY page? The title of the paper (and usually the date) -- that's the H1. Sure, it's bigger on the front page, but in terms of structural importance [i](as opposed to important importance -- there's a difference and people screw that up reading the specification's legalese every time)[/i] they're all H1... Some people would say "what about the headline, that's the biggest text on the front page" -- and? STRUCTURALLY you aren't saying that "Woman found dead on Maple Ave" and "K-6 get new building" are subsections of "[b]MAYOR CAUGHT TAKING BILLION DOLLAR BRIBE[/b]" -- they're all H2, siblings to each-other and subsections of the paper. [i]Either that or you're in one really screwed up town.[/i]. Likewise there's "horizontal rule" -- which people seem to think means "draw a line across the page" -- while that's the default appearance, in professional writing you'd use a horizontal rule to indicate a change in topic where a heading is unwanted or unwarranted. So it is in professional writing, so shall it be in HTML.
[i]...and when you get into HTML 5 you'll find they pissed all over this with the pointlessly redundant SECTION, NAV, ARTICLE and FOOTER tags[/i]
Many of the tags that have semantic meanings thanks to their being used as a markup specification people THINK are presentational, when they are not. B and I (bold and Italic) for example do NOT mean "this text must be shown as bold and italic" because when TBL made HTML not every device was even capable of showing bold and italic. They mean "would be bold or italic in a properly written document" -- which is to say for things like proper names, books, etc... you'll often hear ignorant halfwits saying "use STRONG and EM instead" or worse, "B and I are deprecated" -- the former is often bad advice, the latter is 100% grade A farm fresh bull. EM and STRONG mean "emphasis" and "with more emphasis" respectively -- you aren't emphasizing the title of a book, you aren't adding more emphasis just because you mention the name of a company. B and I's semantic meaning of "would be bold or italic in a professionally written document" still has it's place.
more than anything, when you start making a page you should start with what you want on the page in plaintext or IMG links (and I mean content images, not images as text crap like some incompetent fools do with menu buttons and the like); that's your content. Just put it -- or at the very least a reasonable facsimile of future content -- into a normal flat text editor and arrange it into an order that makes sense as if HTML never even existed.
You then go through and add your semantic tags to say what things are... Your headings to break it into sections so you have a logical document structure, A (anchor) around your links, menus being lists of choices get lists, bullet point lists get lists, paragraphs around your actual grammatical paragraphs -- keeping in mind a lone image is NOT a grammatical paragraph, a sentence fragment in the middle of nowhere is NOT a paragraph. These large blocks of text in this post separated by periods and spaces into sentences? THAT'S A BLOODY PARAGRAPH. (It's often shocking where people just throw paragraph and to hell with it's meaning).
This gives you a semantic baseline... which means search engines, screen readers, braille readers, and people who block fancier bits of tech because their connection or bandwidth sucks will have a useful, if rather plain page. That's the first step in what is commonly called "accessibility".
THEN and ONLY THEN do you start worrying about the page's appearance, and that's the job of CSS, sometimes with a bit of assistance from the two semantically neutral tags "DIV" and "SPAN", which are 'block-level' and 'inline-level' respectively. You should at least TRY to style as much as possible without adding extra tags, but at this point you probably will end up adding a good number of DIV and even a few SPAN. Those tags exist to group elements together for styling WITHOUT saying what that style IS...
[i]Which is why HTML 5's SECTION, NAV and FOOTER are also silly, you shouldn't be using tags with "meanings" redundant to existing tags with meanings you should already have on the page just as styling hooks.[/i]
.... to be continued (10k post limit is really annoying guys!)
reply?
0
@deathshadowJun 13.2014 — #... continued When it comes to making your CSS Layout[b]S[/b] -- you need to remember to keep that plural. With the plethora of device capabilities, default font rendering sizes (on which your layout should be based, none of that pixel measurement garbage), screen resolutions and PPI, you are best off making layouts that are semi-fluid (expand and contract to fit with a upper-limit set by max-width), elastic (fonts and layout auto-expands/contracts based on the default font size) and responsive. (The new kid, and the next logical step in accessible design, changing the layout based on the available screen space).
CSS is the hard part... that's gonna take you a while to learn... but the core of it is that HTML is for saying what things ARE, CSS is for saying what they look like... on specific targets.
Then and ONLY then do you start thinking about dicking around in Photoshop or some other paint program to make the graphics you hang on the layout (if any, thanks CSS3!!!), Then and ONLY then should you enhance the page with JavaScript.
There's an ... unwritten rule to JavaScript "If you can't make the page work without scripting FIRST, you likely have no business adding JavaScript to it!" -- but really that applies across the board to EVERY client side enhancement you make to a page and it's content. JavaScript, CSS, HTML -- if any of those are missing, is the page still at least delivering the content? That first and foremost is the goal, and the reason HTML even exists, CSS even exists, and why you "progressively enhance" the page -- with HTML, with CSS, with presentational images, with scripting -- so if any of those along the way fail, are unavailable, or are intentionally blocked, the page "gracefully degrades" while remaining usable.
... a concept lost on a lot of the PSD Jockeys and Script-tards out there; who piss out flashy and very pretty pages, that are ultimately useless to large numbers of users as they drool all over the place and when pressed go "Accessibility, what's that?" or worse "Who gives a ****?" -- great plowing attitude right there.
I would also suggest you at least TRY to read the WCAG -- web content accessibility guidelines:
But beware like every other W3C specification it's written in hard to decipher legalese; be familiar with it, but really there are three major points that stand out above everything else once you hit the design stage...
1) Elastic/Dynamic fonts -- Avoid declaring fonts in pixels unless you absolutely have to (like an image background interaction on a button). They are inaccessible crap for large font/120dpi users like myself, sending us diving for the zoom. There is more to web design than the default font and pixels per inch you happen to be seated in front of.
2) Fluid or semi-fluid layout -- Avoid fixed width design, it will piss somebody off somewhere at some time, particularly when combined with the first of these little screwups since if you dive for the zoom and end up stuck side-scrolling, you're REALLY going to piss people off.
3) Legible colour contrasts -- Certain colour combinations are illegible. Don't use them. There's math for checking background vs. foreground colours; I've gone over that in so many posts lately... I'll just post a link to a recent one:
Middle of that post I outline the formula, which is pretty much what the WCAG recommends, and can also be found in a joint usability study by Apple, IBM and M$ that worked it's way into the UI design guidelines for all three companies, as well as the VGA specification itself.
Sad part being most people making UI's and talking about UX (user experience) have thrown that in the trash, and don't know the first thing about usability -- and instead are using the term UX to justify their sleazy, bloated, slow loading and ultimately useless trash like some sort of lame excuse.
Which I also recommend reading this article, so you can recognize the lame excuses when you encounter them:
Oh, and one other thing, comments; good commenting is good coding, pointless and bad commenting is worse than having none at all. Even though it's meant for C programmers, I think anyone writing code be it actual programs or markup/stylesheets can benefit from this article:
I'm particularly fond of the "oh, now we're done" part as you'll often see that scale of ineptitude in HTML.
<!-- start content -->
<div id="content">
No, REALLY? A DIV with the ID "content" on it is the start of the CONTENT? Whoddathunkit?!?
Also beware that comments -- yes, COMMENTS, the part browsers are supposed to ignore -- can trip rendering bugs in some versions of IE and FF. No joke... IF they end up between sibling elements that are floated or recieve positioning they can randomly trip either the 'double render' bug or 'disappearing content' bug -- which their names say EXACTLY what they do.
So a nice trick to avoid that, don't use idiotic opening comments like above, and if you want a closing comment instead of:
</div><!-- end content -->
Move it inside the close (and don't say "end", that's what </div> already means!)
<!-- #content --></div>
Notice I use the # to say it's an ID being closed. Because it's inside the close it can never be between sibling elements, dodging that particular annoying bullet I've seen people waste massive amounts of hacks and extra elements to try and sneak past.
Ok, I'm starting to ramble, but hopefully you can extract some useful bits from between my hating on HTML 5 and insulting the mental faculties of most of the people calling themselves "designers" who don't know enough HTML, CSS or accessibility to be designing but two things -- and Jack left town. ?
reply?
0
@NogDogJun 13.2014 — #If you want to get into the full front-end development thing, then you'll have to know JavaScript (which has virtually nothing to do with Java, by the way) in order to do all the fancy user experience things everyone feels they must have these days.
If you want to be a one-person web shop/freelancer, though, then you start talking about server-side programming and databases, which is a whole 'nother package of skills (and maybe mindset?). I'm personally more interested in and better at the server-side stuff and that's what I specialize in at my current job (besides which my artistic skills are pretty much at the level of "I know a good design when I see one, but I don't know how to get there from scratch").
reply?
0
@deathshadowJun 13.2014 — #Oh, and if you are coming from a visual background -- this IS going to be hard for you. The laugh is once you grasp the concepts, it's WAY easier and far more productive than dicking around in some goofy WYSIWYG or sliding layers around in some even goofier paint program... and the end result will stand head and shoulders over ANY site built with the "what it looks like" first approach, which is pretty much putting the cart before the horse.... especially if you can learn to stay the blue blazes away from goofy crap like scripttard animations for nothing, JS that replaces HTML functionality, massive background images that have no business on websites in the first place, and all the other "designer" nonsense that does nothing but get in the way of doing what's actually important on a website.
Delivering CONTENT to users in as accessible and speedy a manner as possible; because at the end of the day people do NOT visit websites for the flashy graphics or goofball animated garbage you hang around the content, they visit FOR the content.
Which is why some of the BEST web designs are the one you'd never actually go "hey, cool design" -- because if you notice the design before you notice the content, there's something wrong with the design... or the content! [i](or in most cases, BOTH!)[/i]
Just look at the big success stories of the Internet -- Google, facebook, twitter, Amazon, eBay -- not exactly a visual tour-de-force that makes you think someone sat there for hours playing around in Photoshop, are they? Even when they are an inaccessible poorly coded mess, their design is simple and content oriented -- because they know what's important. Delivering their content to visitors like you and I.
reply?
0
@NogDogJun 13.2014 — #Yeah, if you have "heroin content", you don't need shiny objects to attract people to it. ? (And I've been driven away from more than a few web sites without ever sampling their content due to the headaches instilled by all their shiny objects. ? )reply?
0
@jedaisoulJun 14.2014 — #There is lot of merit in what deathshadow says, but there is a counter argument to his claims re "elastic fonts"...
Elastic/Dynamic fonts -- Avoid declaring fonts in pixels unless you absolutely have to (like an image background interaction on a button). They are inaccessible crap for large font/120dpi users like myself, sending us diving for the zoom. There is more to web design than the default font and pixels per inch you happen to be seated in front of.
[/QUOTE]
Deathshadows comments seem to be based on the idea that fonts declared in pixels are fixed to the respective size. Whereas fonts in EMs can auto-scale to different pixel sizes in response to the default font size set in Windows or Linux. Sounds a great idea? However, the reality, as I understand it, is somewhat different:
So, it seems that there is little [i]practical[/i] benefit in declaring fonts in EMs. Furthermore, manually zooming the display is not the only alternative. As I understand it all the major browsers allow you to set a default zoom level, which scales graphics as well as text. It does not care whether settings are in EMs or PXs, and is not linked to the OS setting.
Furthermore, there is at least one good reason why linking the default zoom of text (or graphics) to settings in the OS is not a good idea: It's a real pain to test. This is because changing the default font size in the OS, (to see whether the browser responds) gratuitously rearranges the icons on the desk top. Ouch!
reply?
0
@deathshadowJun 14.2014 — #1. The idea of scaling the text (whilst leaving graphics unaltered) suggests that people with impaired vision need text to be magnified, but not graphics. Why?[/QUOTE]
Two good reasons -- first browser scaling of images looks like ass... and not hot juicy playboy ass, but don't wear that thong cottage cheese ass. Second, enlarging template images would consume screen space better used for delivering what's actually important -- CONTENT!
2. Browsers on Apple's Mac OS have never supported this feature.[/quote]
Excepting of course Firefox and Chrome... which do... and I had thought Safari supported it too ; but I can't test that right now as I no longer have a working OSX install here - one of the things I need to fix.
3. Mobiles do not support this feature.[/quote]
Excepting Opera... and Blazer... and whatever the **** RIM is using right now...
...and the version of Chrome that comes with most Android devices. Settings > Accessibility > text-scaling
4. AFAIK only obsolescent Windows and Linux browsers support this feature.[/quote]
You mean Chrome, Opera, ICEWeasel, Konqueror and Firefox are "obsolete" browsers? REALLY?
You can set it manually in the settings of ALL those browsers...
Chrome:
Firefox: (you MAY have to go into :config to change a value on windows if large fonts is OS enabled)
ChrOpera: (aka the pathetic crippleware Opera)
Opera 12.x:
In the webkit browsers the choices in that dropdown are: medium == 16px, large = 20px, X-Large == 24px as the default size. Not sure what the smaller sizes are, but they are likely 12px and 8px. (not that I could ever see anyone choosing 8px)
Furthermore, there is at least one good reason why linking the default zoom of text (or graphics) to settings in the OS is not a good idea: It's a real pain to test. This is because changing the default font size in the OS, (to see whether the browser responds) gratuitously rearranges the icons on the desk top. Ouch![/QUOTE]
Except you can also set it IN THE BROWSER separate from the values above. I usually have Opera 12 (my primary browser), ChrOpera and FF locked into the large font behavior, and Chrome/IE not. It can be inherited from the OS (in OS that actually care about users like Windows), [b]or[/b] you can set it manually.
We were talking about this via PM last week, and I'm not understanding why you seem to be having so much trouble finding such an easy to use (and commonly used) setting... It's almost like you just don't want it to be true or something.
reply?
0
@jedaisoulJun 15.2014 — #
Two good reasons -- first browser scaling of images looks like ass...
[/QUOTE]
To people with impaired vision? I doubt it.
Second, enlarging template images would consume screen space better used for delivering what's actually important -- CONTENT!
[/QUOTE]
"Better used for content" is a subjective view, not a matter of fact. Designers use template images, and size them to suit the overall aesthetic of the design. Do some designers overuse graphics? Yes. Does that invalidate all use of template images? No.
You mean Chrome, Opera, ICEWeasel, Konqueror and Firefox are "obsolete" browsers? REALLY?
You can set it manually in the settings of ALL those browsers...
[/QUOTE]
PRECISELY!!! The settings are in the browser, NOT inherited from the OS.
Except you can also set it IN THE BROWSER separate from the values above. I usually have Opera 12 (my primary browser), ChrOpera and FF locked into the large font behavior, and Chrome/IE not. It can be inherited from the OS (in OS that actually care about users like Windows)...
[/QUOTE]
But Windows 7 and 8 do not suppport the setting of the default font size without also scaling images.
We were talking about this via PM last week, and I'm not understanding why you seem to be having so much trouble finding such an easy to use (and commonly used) setting... It's almost like you just don't want it to be true or something.
[/QUOTE]
On the contrary, I was much impressed by your exposition of the benefits of using EMs, right until you said:
Thankfully for FF there's an extension for handling the theme font size:
https://addons.mozilla.org/en-US/fir...-size-changer/
Linsux is quite similar, you have to set it manually for each browser since WM manager settings are outright ignore
Which is why the current state of things is this inconsistent jumble, which along with the new color choices used by OS has accessibility experts screaming "WHAT THE ****!?!" at all three major OS vendors.
Basically what you are encountering is that RIGHT NOW, the whole state of affairs is a giant mess; Java swing crapplets don't obey it, QT and GTK programs don't obey it automatically -- but stuff written with Visual Studio, Delphi, Metro, or the classic Win32 API do, unless the programmer overrides it out of ignorance, or like on browsers somehow thinking PX is "easier". (which it isn't)
Still, just because browser makers, much like the idiotic halfwit train wreck of ineptutude known as HTML 5, are going "accessibility, what's that?" is no reason to not follow the WCAG; much like the people who still sleaze out tables for layout, and still can't build a forms using the actual RULES for building a form that have existed since the FORM tag was added to the specification -- it's just ignorant nonsense to declare fonts in PX, fixed widths on content, etc, etc...
[/quote]
You may feel otherwise, on principle, but based on your own comments, surely any person who does not already use EMs would conclude that there is little [i]practical[/i] benefit in using them??? Also I am yet to be convinced that this is a valid [i]accessibility[/i] issue. Some users, like yourself, [i]choose[/i] to set different font sizes without resizing images but that is a matter of preference, not accessibility. Should something as fundamental as the use of EMs rather than PXs be based on the preferences of a small number of users?
reply?
0
@deathshadowJun 15.2014 — #To people with impaired vision? I doubt it.[/quote]
Not everyone who uses it has impaired vision; many of us do so to avoid jaggies or just because their displays have higher PPI and they don't feel like keeping their nose plastered an inch from the display.
When I first started using the setting TWENTY-FOUR years ago on Windows 3.0, most people were running 640x480 on 14" CRT's... we didn't have font smoothing, and the jaggies on some fonts were absolutely dreadful; running 800x600 or 1024x768 at 8514/large fonts reduced the jaggies by introducing more PPI.
Today my workstation runs 2560x1440 at 27" -- which in reality works out to many more pixels per inch than a 24" 1920x1200 -- which works out to many more pixels than the typical el-cheapo 21" 1440x1024 -- and now we have 1920x1080 21" displays -- and my 17" laptop is also 1920x1080...
... and lately, to be frank, I'm worried about back strain in others watching the way they hunker over their laptops or across the desktop screen. It's actually more scary than the allegedly ergonomic garbage of the early '90's that was more placebo than fact.
But Windows 7 and 8 do not suppport the setting of the default font size without also scaling images.[/quote]
I still have no clue what you mean by that -- unless you're talking about the auto-swap internal of ICO's on supported one and enlarging of ones that don't have the MPF (multiple pixel format) version of WMF (windows metafile format)... though admittedly, developers who don't make applications for Windows seem blissfully unaware that ICO files can store multiple resolutions of the same image from 16x16 to 256x256; in multiple colour depths.
But what that has to do with image scaling is beyond me... since if I open a image in PSP, Photoshop or Paint it isn't auto-zoomed. I open image in irfanview it's not auto-zoomed... I open a word document or PDF the behavior is no different... and if I have the browser set to the behavior we're talking about... well, do I have to say it?
You may feel otherwise, on principle, but based on your own comments, surely any person who does not already use EMs would conclude that there is little [i]practical[/i] benefit in using them???[/QUOTE]
I'm sorry, but to me that's the "just because some people don't use it nobody needs it" attitude -- JUST because java swing crapplets, QT and GTK don't support it [i]by default[/i], doesn't mean ALL THOSE ONES I LISTED THAT DO -- including 90%+ of windows applications -- don't... and you can be pretty well guaranteed the people who 'need' or just use it (and there's a difference) are going to use applications that don't... and that's the message. Don't alienate potential users.
ESPECIALLY when anything built with Metro or the Win32 api do support it -- that's only what, 95% of desktop applications?
Though it does seem a LOT of things now have the "only a few people use it, so who needs it" attitude; see the pathetic crippleware known as ChrOpera that removed everything making Opera worth using over other browsers -- or the repeated dumbing down of OS UI with the likes of Windows 8, Gnome 3, and OSX that are more concerned with being new for new's sake, and who cares about lost functionality.
It's really starting to piss me off across the board on just about everything computer related -- you figure in the halfwit garbage of sleazy shortcuts for EVERY level of development, and dialing the clock back to the worst of late '90's coding practices that is the steaming pile of manure known as HTML 5...
[i]If this is the future, I think I'll pass.[/i]
reply?
0
@NogDogJun 16.2014 — #I have impaired vision -- not legally blind type, but debris in one eye from a torn retina as well as a macular pucker (on top of being pretty near-sighted). When I have to hit Ctrl-+ a couple/three times to make a web page legible, and some non-essential graphic (i.e. decoration, not content) starts taking up more screen space, it can be a pain in the ass, depending on how the page is laid out. If I set a minimum font size in the browser preferences, you'd be amazed (or maybe not?) how many web site designs break to some degree as a result.Unfortunately, lots of web pages are designed and implemented by 20-somethings with youthful eyes, who for some reason feel their designs look better with 8-point Helvetica in some shade of medium-dark gray, and who don't test them to play nicely with people like me. :rolleyes: (If you stop by our office, I'm the guy with his monitors no more than a foot away from his nose, using a larger font in his code editor than any of the other developers. ? )
reply?
0
@deathshadowJun 16.2014 — #I have impaired vision -- not legally blind type, but debris in one eye from a torn retina as well as a macular pucker (on top of being pretty near-sighted).[/quote]
I'm actually legally blind now, but that's because I can't read street signs more than 15 feet away, inside that distance I'm as if not better sighted than most people; much of that being my larger field of view and lack of tunnel vision regardless of what I'm doing.
In my case it comes from a dislocation of my right eye from explosive decompression some 14 years ago. Fun stuff.
If I set a minimum font size in the browser preferences, you'd be amazed (or maybe not?) how many web site designs break to some degree as a result.[/quote]
Or if you DARE to actually use the zoom.
... and that's WHY I advocate all the design and development practices I do -- if you make the page elastic, it will auto-adjust to the users font size choices. If you make it fluid (or semi-fluid) it will adjust to the available space, but the layout will ALSO adjust when you zoom, preventing it from breaking. Likewise the new kid -- responsive layout -- can be set to re-arrange the layout to fit the available space, and that too supports not just the elastic fonts, but zooming as well.
It's also the origin of the "trifecta of /FAIL/" at web design: Fixed width layouts, px metric fonts, illegible colour contrasts. All three amount to the same failing, making it harder for users to get at what's important -- the content.
Take fixed width layouts for example: They are either 'crappy little stripes' on big displays, or broken and useless on smaller ones; Whenever people ask "what width should I design to" I [b]KNOW[/b] they have either been led down the garden path by someone who doesn't know enough to be telling them how to build a site, or are SO deeply ingrained in 'what things look like' in front of them, they cannot grasp that what's in front of them isn't what everyone has. See the lame "800px friendly" of the previous decade, and the "1024 friendly" crowd of today -- all of whom missed the boat the moment mobile came along and pissed all over that with sizes ranging from 192px wide to 1080p tablets.
There have ALWAYS been the lame excuses people come up with to justify their even lamer development practices -- oh this is only x% of users... Oh everyone has broadband now... Everyone is using multi-ghz processors with multi-gigs of RAM... and to be frank, I've been hearing that crap for FIFTEEN YEARS and every single time it's been one big fat steaming load trashed by "the next big thing".
If you build elastic, semi-fluid AND responsive, you have pretty well covered the bases -- meaning the number of places it CAN break are eliminated. It's not rocket science, it's not hard... people MAKE it hard. They make it hard by not bothering to learn how to use HTML 'properly' (aka semantic markup), not bothering to use all the good practices like progressive enhancement and graceful degradation, and so forth.
See why there are certain design concepts -- like multiple equal-height, equal-width containers across a page, "rotators" / "Banner animations" with paragraphs of text inside them, and so forth, IMHO have no place on a site design if you care about accessibility... or should I say "Visitors actually WANTING to use your website". But then there's a reason to me things like that -- along with the artsy fartsy picture heavy themes, and goofy JS for nothing animations people use -- amount to little more than sweeping under the rug a lack of content, or worse developer incompetence.
In many ways, a well written website should be... well, a certain martial artist put if fairly well:
[i]"You must be shapeless, formless, like water. When you pour water in a cup, it becomes the cup. When you pour water in a bottle, it becomes the bottle. When you pour water in a teapot, it becomes the teapot. Water can drip and it can crash. Become like water my friend.”[/i] -- Bruce Lee
You load a well written website on a phone, it becomes the phone. You load it on a tablet, it becomes the tablet. You load it on a desktop, it becomes the desktop.
Of course, that 90% of the tutorials online and 95%+ of the books on shelves are 1997 scale web rot written by people who never learned to use HTML 4 properly certainly doesn't help... much less the dreadfully confusing legalese used in making the W3C specifications; when simple words like "empty" and "important" don't mean what normal people use those words for; how confusing must it be when words not used outside of courtrooms like "deprecated" or "normative" are in the mix?
I mean I can grasp the specification after YEARS of studying it, but when <div></div> is not what they mean by an "empty" element and <h1> doesn't mean "more important" than a <h2> in terms of importance on the page, but import to document structure (two entirely different things) I can't help but wanting to knee-jerk into doing a Samuel L. Jackson impersonation, getting medieval on people's rumps with "Englisc, mōdor wyrter! Gedōn ēow cweþan hit!?!"
Unfortunately, lots of web pages are designed and implemented by 20-somethings with youthful eyes, who for some reason feel their designs look better with 8-point Helvetica in some shade of medium-dark gray, and who don't test them to play nicely with people like me.[/QUOTE]
Actually you want a laugh, I'll see if I can find the study. There was some research done that showed that older developers were usually MORE likely to use smaller fonts... which struck me as odd since I always thought it was the other way around too.
Hmm. Striking out on finding it, it was three or four years ago, but my google-fu fails me.
reply?
0
@jedaisoulJun 16.2014 — #I think I need to clarify what we are, and are not, talking about:My points are:
a) I do not agree that, as an [i]accessibility feature for partially sighted people[/i], that it is necessary, or even beneficial, to SEPARATELY set the default font size as opposed to zooming the display (whether set in the OS or browser).
b) Linking the setting (default font or zoom) to the OS is unnecessary and a pain in the butt to test, as resetting the default font or zoom trashes the icon positioning on the OS desktop.
Now, turning to your points:
Not everyone who uses it has impaired vision; many of us do so to avoid jaggies or just because their displays have higher PPI and they don't feel like keeping their nose plastered an inch from the display.
[/QUOTE]
Then zoom the display. This does not necessarily lead to "jaggies". E.g. At 125% on a 120ppi a 96px x 96px image is the same size as on a 96ppi display set at 100%.
When I first started using the setting TWENTY-FOUR years ago on Windows 3.0, most people were running 640x480 on 14" CRT's... we didn't have font smoothing, and the jaggies on some fonts were absolutely dreadful; running 800x600 or 1024x768 at 8514/large fonts reduced the jaggies by introducing more PPI.
[/QUOTE]
Funny, my recollections are somewhat different. Compared to the 320 x 200 CGA displays I was used to, 640 x 480 VGA was wonderfully smooth (and had a 1:1 aspect ratio). The smoothness was probably helped by the limited resolution of the color CRT screens of the day. Jaggies on VGA screens only became noticeable (to me) when I purchased a Sharp laptop with a back-lit monochrome LCD display. However as the jaggies were a hardware feature, software scaling of fonts and/or images would have had no beneficial effect anyway.
... and lately, to be frank, I'm worried about back strain in others watching the way they hunker over their laptops or across the desktop screen. It's actually more scary than the allegedly ergonomic garbage of the early '90's that was more placebo than fact.
[/QUOTE]
Like I said, they can always zoom the display instead (dynamically or by resetting the default zoom).
I still have no clue what you mean by that --
[/QUOTE]
I mean that Win 7 and 8 only support zoom scaling of the desktop.
But what that has to do with image scaling is beyond me... since if I open a image in PSP, Photoshop or Paint it isn't auto-zoomed. I open image in irfanview it's not auto-zoomed... I open a word document or PDF the behavior is no different... and if I have the browser set to the behavior we're talking about... well, do I have to say it?
[/QUOTE]
So why should web browsers treat EMs different to PXs?
... and that's the message. Don't alienate potential users.
ESPECIALLY when anything built with Metro or the Win32 api do support it -- that's only what, 95% of desktop applications?
[/QUOTE]
Like I said, in 7 and 8, (at least in the 64 bit versions I have access to) that functionality appears to have been dropped, at least so far as the OS is concerned.
Though it does seem a LOT of things now have the "only a few people use it, so who needs it" attitude; see the pathetic crippleware known as ChrOpera that removed everything making Opera worth using over other browsers -- or the repeated dumbing down of OS UI with the likes of Windows 8, Gnome 3, and OSX that are more concerned with being new for new's sake, and who cares about lost functionality.
It's really starting to piss me off across the board on just about everything computer related --
[i]If this is the future, I think I'll pass.[/i]
[/QUOTE]
I have given the reasons why I conclude that there is little [i]practical[/i] benefit in using EMs instead of PXs. I also question its validity as an [i]accessibility[/i] feature anyway. It seems to me that nothing you have said changes either of those views.
reply?
0
@deathshadowJun 16.2014 — #1. We are talking about the ACCESSIBILITY feature of web browsers to inherit from the OS the setting of the default font size independent of the size of graphic images.[/quote]
No, that's only HALF of it, as you can set it in the browser independant of the OS as well! Sure good browsers notice it by default, [b]but that does not mean you can't change it to your own custom choice in the browser as well! HENCE ALL THOSE SCREENCAPS I POSTED!?!?!?!?!?!?![/b]
but appears to be absent in Win 7 and 8 (afaik).[/quote]
Which.. it isn't absent... at all... no idea what you're even on about. Hell, they made it easier to get to and added more options! Unless they did something stupid to Home/Basic or something (neither of which I have)
a) I do not agree that, as an [i]accessibility feature for partially sighted people[/i], that it is necessary, or even beneficial, to SEPARATELY set the default font size as opposed to zooming the display (whether set in the OS or browser).[/quote]
Well, that's great for you -- but see NogDog's post? Again "I don't need it so **** everyone else" is not a great attitude for web development!
Linking the setting (default font or zoom) to the OS is unnecessary and a pain in the butt to test, as resetting the default font or zoom trashes the icon positioning on the OS desktop.[/quote]
EXCEPT YOU CAN ALSO MANUALLY SET IT!!! [b]IN EVERY BROWSER![/b] [i]I even just tested, and it's in Safari on OSX too so...[/i]
Then zoom the display. This does not necessarily lead to "jaggies". E.g. At 125% on a 120ppi a 96px x 96px image is the same size as on a 96ppi display set at 100%.[/quote]
Uhm... no... I zoom 125% regardless of ppi it goes all *ugly as sin. Zoom is often NOT a desired behavior -- more so when some idiot slaps things into a fixed width layout.
Funny, my recollections are somewhat different. Compared to the 320 x 200 CGA displays I was used to, 640 x 480 VGA was wonderfully smooth (and had a 1:1 aspect ratio).[/quote]
With raster fonts sure, you started showing truetype it looked like ass. Honestly CGA raster fonts at 640x200 were often more legible than truetype or postscript was at 640x480... but at that time we were dealing with truetype and postscript because desktop publishing was "The big thing" of the time. [i]and why I HATED dealing with it on the mac with it's fixed 72dpi displays![/i] -- scaleable fonts were the future, but the hardware really hadn't caught up yet.
So why should web browsers treat EMs different to PXs?[/quote]
Because it's a different measurement with a different meaning? Because moving forward PPI is going to climb? (what with 4k displays now coming in 29" and smaller flavors?) -- though what that question has to do with what you quoted is beyond me; I'm wondering if you comprehended what I said at ALL.
Like I said, in 7 and 8, (at least in the 64 bit versions I have access to) that functionality appears to have been dropped, at least so far as the OS is concerned.[/quote]
Which you must be doing something wrong or changing the wrong setting, or have ticked the wrong box. It behaves here for me in Win7 JUST like it has since nineteen-freaking-eighty-nine when it was called "8514 fonts".
Type this into explorer's (windows explorer, not IE) address bar:
Control PanelAll Control Panel ItemsDisplay
Which [b]should[/b] be the default page you get going to display from the control panel, or from 'personalize' [i](bottom left corner on the latter)[/i]. It's the first bloody page -- has the title "Make it easier to read what's on your screen"?
Small, Medium, Large, X-Large... corresponding to 16px, 20px, 24px and 28px... They've just given us more options on it than the original Small (16px) and Large (20px).
Are you using the goofy DPI setting thing that was introduced in win98 and NEVER worked right or something? The one under "set custom size"? Because THAT's unreliable and NOT the setting we're talking about. That's actually a vestigial leftover from sharing code with winCE/mobile... kind of like some of the useless broken stuff seeping in at the corners into Safari -- like it's broken implementation of the -webkit-text-resize property. [i]Which if used breaks desktop zooming, but not mobile zooming!?![/i]
Though that one is handy when setting up a system for ten foot operation.
I have given the reasons why I conclude that there is little [i]practical[/i] benefit in using EMs instead of PXs. I also question its validity as an [i]accessibility[/i] feature anyway. It seems to me that nothing you have said changes either of those views.[/QUOTE]
Then you're either blind to it working, or doing it wrong. Though you seem to claim it doesn't exist and/or doesn't work on PLATFORMS I USE IT ON DAILY... So I really think you're either setting the wrong things, or being deliberately obtuse about it.
There's a reason the WCAG says to do it, there's a reason [b]it is in fact supported in every browser as a in-browser setting[/b], there's a reason it's in windows from Win 3.0 right through to 8.1... Gnome and KDE both have a degree of support for it too, and while it's not inherited by browsers on *nix platforms, [b]AGAIN IT EXISTS AS A OPTION YOU CAN MANUALLY SET IN EVERY BROWSER![/b]
Making me wonder just what the blue blazes you are on about with it allegedly "no longer existing"... since to be brutally frank, that's 100% grade A farm fresh horse dung. IT'S RIGHT FREAKING THERE!!! (lord knows I've given you the instructions enough blasted times by now!)
... and again, just because YOU "don't need it" or can't figure out how to use it, doesn't mean those of us who do use it and rely on it should be given a kick in the crotch by what is -- to be brutally frank -- the train wreck of developer ineptitude that is declaring font sizes in pixels and widths of flow content areas in pixels.
Sorry, but... damn... Herpafreakingderp buddy...
reply?
0
@rubyrobertsJul 15.2014 — #Im doing the links for a reply?