I'm trying hard to understand the proccess of W3C's workflow. The main thing that I'm trying to understand at the moment is how do they choose what level is particular CSS module.
For example there is only "CSS Intrinsic & Extrinsic Sizing Level 3" and no information about what was happening to this module before, was it ever level 2, or it started from level 3?
And another, bonus question, why some modules in "Working Draft" status are supported wider by browsers than modules in "Candidate recomendation" status.
How do they choose what level is particular css module?
From the CSS 2017 Snapshot:
Modules with no CSS Level 2 equivalent start at Level 1; modules that update features that existed in CSS Level 2 start at Level 3.
Why some modules in "Working Draft" status are supported wider by browsers than modules in "Candidate recomendation" status?
Writing specifications and implementations of them are iterative processes. Problems with existing specs such as missing capabilities or undefined situations are identified, and initial specifications may be written to address them. Then browser makers may prioritise them according to commercial advantage balanced against ease of implementation, or even if an individual developer or group has a particular interest or skill in that area. This in turn leads to knowledge about what works and what doesn't which then gets fed back into producing a better spec. These iterations can continue indefinitely until all the browser makers are satisfied that they've got the spec right and that sufficient implementations meet that spec. Only then can it proceed to recommendation. Each module proceeds at its own pace, and so there are no rules as to where each one is in the process relative to other CSS specs.
Many developers/accessibility experts suggest to disable CSS for checking the website for accessibility, but no one explicitly says how it may actually be helpful in terms of web accessibility.
So here I am, asking you exactly that, because all my attempts to check this in reliable (I WANT TO BELIEVE!) sources like "w3.org", including their WCAG 2.0 recommendations, don't say anything about making website accessible without CSS. Moreover, they say it may be "relied upon" some technology, like CSS, for example.
You no longer need to explicitly verify that pages are readable without CSS, but it can be useful as a technique for ensuring correct reading order.
The requirement to make pages readable without CSS is a carryover from the days when Section 508 was the dominant accessibility standard.
36 CFR Parts 1193 and 1194 - Published February 18, 2017
There is no direct analogy in the WCAG 2.0 Success Criteria for section 1194.22(d) of the existing 508 Standards, which states: “documents shall be organized so they are readable without requiring an associated style sheet.” 36 CFR §1194.22(d).
https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/single-file-version
WCAG 2.0 addresses this same issue in a different way with Success Criterion 1.3.2 - Meaningful Sequence.
One of the techniques for meeting this criterion is making the DOM order match the visual order (C27), which is largely what this comes down to anyway.
I would say that a good reason to actually disable CSS in terms of checking accessibility is to see that your site structure is built up in a logical way.
On the other hand, a better way to test this is to use a screenreader and tab through the site using use tab / shift + tab with a keyboard. In that way you do not only get an eureka-moment on structural issues you also get the audio-feedback that will give you lots of AHA:s about phrasing, ARIA-issues and hidden elements not hidden in a accessible way.
I'd point you to try out ChromeVox
If you use the accessibility testing tool Wave you can actually disable styles in the tool. So, as built in a testing tool it's a great way to test the structural element flow. There is no purpose in itself to disable CSS besides testing accessibility in this way.
I'm experimenting with CSS Transitions these days. I'm trying to build an animated web page with solely CSS.
Everything works just fine, but I came across an organisation-related issue: My CSS file look like a mess! If the client asks me to delay a specific animation or changing the order of another - It takes me few moments to find the right line to do that (few moments = too much).
May I separate animation-command from pure-design-css? How should I design browsers prefixes CSS (one line or several)? Changing animation speed must be as easy as a click (but now I need to type it 5 times).
I'd be glad to hear some ideas about CSS Trnasitions code organisation.
Thank you!
CSS files should be organized regardless of their content (transition rules etc.), this contributes both to browser's parsing, and to the file's readability in general. Note that:
You should order your CSS according to the rules specification and the cascade (obviously), also aggregating duplicate rules wherever possible.
It is highly recommended to add a table of contents, see example in this article on CSS files organization.
You better order key-value pairs in a consistent manner (e.g. alphabetize them) as recommended at google's 'make the web faster' article on payload.
So we should make accessible web sites, providing alt attribute for img elements and all other stuff. But although this effects comparatively lesser number of users, I could not find any information to the issues that effects each and every user.
Let me explain. If we were to simplify matters by saying that web sites should provide the most revelant information in the least amount of time, would I be wrong? Given this axion if I were to
1 - Want to download the offline version of Acrobat Reader X. There is nothing, and I mean nothing on the site http://www.adobe.com/products/reader.html which provides a hint, link or anything to that. I have to use google to find ftp://ftp.adobe.com/pub/adobe/reader/
2 - Again trying to find the offline version of Google Chrome at http://www.google.com/chrome/ . Nothing there that may lead to http://www.google.com/chrome/eula.html?standalone=1
3 - So Internet Explorer has an addon called Web Developer Tool Bar. It is safe to assume I will find it at http://www.ieaddons.com/in/. No such luck. Have to google it again and find it at http://www.microsoft.com/downloads/en/details.aspx?FamilyID=95e06cbe-4940-4218-b75d-b8856fced535
4 - Trying to get the the Firebug addon from https://addons.mozilla.org/en-US/firefox/extensions/web-development/. Successfully navigated to web development. You can use "view all recetally added" or "view all top downloads" or "view all top rated". What if you want to view all for web development. Offcouse you sue the search!
These are just some of the situations. I guess my question would be that are these not accessibility issues?
If the issues you are are describing apply equally to say sighted users as to blind users using a screenreader, then no, they are not considered to be accessibility issues, but are perhaps broader usability issues.
If, for example, the adobe web site had no link at all to the offline version, and all users, sighted or not, had to do extra work to find it, that's a usability issue.
But if the web site had a graphic image that sighted users could see was a link to the download, but users using a screenreader did not get this information (eg. because the graphic had no ALT text, or the image was not operable via keyboard), then it's an accessibility issue.
There's certainly overlap between these; and it's often the case that usability issues are harder for disabled users to work around; but generally accessibility refers to cases where the design of a site confronts a user with a disability with additional barriers or challenges beyond those that users without a disability have to deal with.
I think it depends on your definition. Some definitions describe accessibility assuming that the correct website is known and is concerned only with the accessibility of that website. Others do describe the ease of users finding the required resource on the Web, which would encapsulate your issues above.
There are two reasons why accessibility is a failure on the web, and for these failures the technology HTML is to blame for both.
1) HTML is not self-validating. SGML does not have a direct self-validating subset and all versions of HTML < 5 are subsets of SGML. HTML5 is based upon a specification document not vested in any computer language, so its perhaps more lost.
XML does have a direct self-validating subset called schema. There are three widely recognized schema languages for XML: Schematron, Relax NG, W3C XML Schema (official).
By self-validating I mean that the language itself can be called to validate its instances without external assistance from the local parser. Without a self-validating component there is no assurance of integrity of a document's structure, and therefore there is no integrity of accessibility. In a world where web browsers will parse anything without regard for the proper well-formedness of a structure then by practice everything is acceptable completely without regard for accessibility.
2) Less obvious and more devastating is that HTML does not understand its own structure. There are two levels of structure as defined in the HTML specifications: block-level elements and inline elements. According to the specifications the difference between these two structure levels is vested primarily in the visual intention of the elements' presentation, which contradicts other language in the specifications in that HTML is a data structure and not a presentational language.
Furthermore, two levels of structure is insufficient and the actual structural definition of HTML elements exceeds a two level structure anyways without inherently stating such. For example in HTML many block-level elements may contain a 'p' element representing a paragraph, but such an element may not contain other block level elements although many other block level elements may certainly contain block level children.
At a minimum a three level structure is required to describe natural language in a manner consumable to a human audience equally without need for further accessibility assistance. In accordance with the structure defined in Mail Markup Language there would be:
Complex blocks
Simple blocks
Inline elements
Complex blocks are purely structural in that they may contain simple blocks, or in some cases other complex block elements, but will never contain inline elements or text nodes. Simple blocks will never contain complex block or simple block elements, but may contain inline elements or text nodes. Inline elements be either singletons containing nothing or will contain text nodes, but inline elements will never contain other elements.
Such a structure is self-sufficient in properly arranging and structuring content so that accessibility requirements are met immediately in a manner where violations of accessibility requirements are more costly and complex than simple conformance to the given structure. Once a sufficient structure is in place all that is missing is the meta data supplied via descriptive and well-known element names, and in some cases additional extraneous content via attributes.
If either of these two items are missing a minimum baseline for accessibility cannot be assured. When they are both missing, as with the web, then accessibility is likely a lost cause and immediate failure.
Web accessibility
Website is made up of different contents like images, texts, videos, button, etc, with combination of different colors.
Web accessibility means that people with disabilities can use the Web.
Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web.
Web accessibility also benefits others, including older people with changing abilities due to aging.
The main theme of web accessibility is creating a website which is accessible to every one. After designing a website it is essential to check the website ADA compliance, whether it is accessible and how much it is user friendly for disabled people.
With different browsers choosing to render CSS in their own preferred way , whats the point of having a standard?
Simple stuff like creating a fluid 3 column layout that works across all browsers can be an experience in frustration. How do you deal with this or make cross-browser compatible development not so painful?
As always, there's a reason behind all this.
The standard is not broken (a standard can't be broken), just that some browsers like IE don't adhere to it completely.
This is mainly because IE was developed before any standard was created and in that time it was the best browser around, with almost zero competitors (I read that netscape was the other option and that it was much worse than IE).
Then people realized that a standard was needed, and they created it obviously not including any of IE proprietary code and features. IE was forced to choose backwards compatibility with it's previous versions, or to adhere to this new "standard", they absolutely ruled the browser market so the choice was obvious.
With new versions IE tried to be more and more standards compliant, and they say that IE8 successfully passes the ACID2 test, so the standard utopia is (slowly) coming to reality.
In the mean time, check this site -> quirksmode that contains useful cross browser information. Also try to check any articles about "IE box model" online, and stay away of padding in IE. If you also use a 3rd party javascript library (JQuery, Prototype, Dojo) you should be fine (or as fine as anyone of us can be).
Regards.
One major point of having standards is to keep us out of another browser war. You know the one where Netscape and Microsoft kept adding as many proprietary features as they could to the browsers. Cross browser development is a breeze today compared to then...
Another good reason for having standards is that you know where future versions of the browsers will be heading. Following the standards is the best prediction that you can get for how future browsers will work.
You can find a lot of cross-browser tips in this question: How can I achieve a consistent layout in all browsers?
Standards are emergent, not pre-defined. Well, at least they should be. Many developers I've talked to seem to find my view of Web standards slightly heretical, but stay with me here.
When you try to create the standard before the implementation, you have several problems:
A long delay before useful implementations appear. Nobody has a working implementation to reference, and since nobody is using any of the standard's features (since it doesn't exist yet), there is little impetus to actually implement it. A chicken-and-egg type of problem.
The potential for standards that cannot actually be implemented. Who knows for sure until somebody actually tries it? The HLA standard was a good example of this happening, to the point where the DoD had to write an "interpretations" memo that attempted to set the de facto standard by glossing over some of the errors in the actual standard.
The potential for standards that don't serve any practical need. Do people actually want this? See example at XForms, which has fallen into a weird, server-side niche. Or, I can't think of anybody I've met who found the CSS "width does not including padding" box model to be intuitive.
An inability for implementers of the standard to distinguish their products from their competitors, resulting in a stubborn desire to break with the standard in practical or lock-in-encouraging ways. See example at CORBA.
I think that the W3C learned this the hard way in recent years. Some of the most end-user visible innovation has come from a new browser war: examples would be HTML5 (several vendors), canvas (Apple), XMLHttpRequest (Microsoft's Outlook Web Access team), input range (Safari's built-in RSS reader), and the video element (Firefox)--these came from the proprietary level on up, not from the standards tower on down. And these new "standards" were forged by looking at these past individual implementations (Firefox copied Microsoft largely for XMLHttpRequest, and so on), not by some wide-eyed think tank pondering the future. (ISAPI, the Netscape plugin API, and SQL are all examples of bottom-up standards, where breaking changes are done gradually in a lock-step fashion.)
A standard should be a least common denominator that smooths over the basic differences in implementations, a pidgin language that works across all of them, and not an enumeration of Robert Lowth-style prescriptive rules about a language or system, because then you end up with rules that don't always make sense or apply a non-realistic ideal (like trying to apply Latin-based grammar rules to a Germanic-based language, like trying to apply XML-based grammar rules to an SGML-based language). Oh well, this is what we've got.
Probably the greatest defect in the CSS standard at this point is that there really isn't a good way to specify that a page was written against a particular version of the standard. We can specify DOCTYPEs for our HTML documents, why can't I indicate that a document was written for CSS 2.1? This will only become more important as we start adding more and more bizarre features to CSS that affect the actual content of the page, such as CSS's :before pseudo-elements. A future version of the standard is going to have errors one day that potentially break compatibility, and it'd be nice to let the document author ask for certain behavior rather than have browsers attempt to figure out the intent.
On the lighter side, though, now that IE8 and IE7 are out, things really aren't as bad as they were in, say, 2005. A specific IE6 stylesheet served with conditional comments can really go a long way to making a CSS/standards-based implementation feasible. The other advice is to use Google, to take the 3-column fluid layout example, and hope that someone else has done most of the troubleshooting for you.
Creating a cross-browser compatible Web site is difficult, standard or no standard. You can make it easier on yourself if you accept that there will be some differences in the way different browsers render your site. Don't be afraid of proprietary extensions by any means (it's all right to have CSS3 rounded corners for your non-IE users), but have a fall-back for when they don't exist (eh, the rounded corners aren't critical for using the site), and let your users choose how they'd like to consume your content.
The other answers to this question pretty much cover the ins and outs of why CSS isn't the problem, but as for how I deal with the cross-browser difficulties, it's normally in roughly 4 steps:
Design the site using firefox, as it has lots of useful extensions (most notably Firebug, which tells you which CSS rules are being applied, which are being over-ridden by other rules, etc.)
Check the site quickly in Safari and Opera to make sure design has no flaws there. Normally it'll work fine as - thanks to the CSS web standard - these browsers render web pages in almost identical ways
View the design in ie7 and use the *+html css filter to correct errors
View the design in ie6 and use the * html css filter to correct errors
to do points 3 and 4 yo would have something like this
.box {css rules}
*+html .box {css rules to override in ie7}
* html .box {css rules to override in ie6}
At the end of all this you will still be left with valid css that works across the major browsers.
Hope this helps
*edit - forgot to add that ietester is a great bit of software that allows you to install multuiple versions of ie on windows xp or vista: http://www.my-debugbar.com/wiki/IETester/HomePage
The standard has some shortcomings. It's also quite a difficult thing to implement. The problem is in the implementation more so than the standard.
Use things like YUI where a lot of smart people have done a lot of hard work to make these things work across various browsers.
The standard is there in the open so that the browsers who do not confirm to the standard may look and learn. The standard is important because it is the only way by which you can HOPE to make a webpage that will display correctly on all pages.
Also remember that a standard that is developed is never for the past, it is only for the future. If in the past some browsers did not confirm to the standard it doesn't mean that we should not have standard.
In fact the standard is born because the browsers were all doing their own thingie and there was then a need for the standard.
If you code to the standard the browsers will confirm to it.
Have a hope pal!
It looks to me that You are just starting with CSS. Because even though the browsers do not adhere to the CSS specification perfectly, there is a lot of safe ground that You can use with confidence. This safe ground is nowadays much larger than it used to be about ten years ago, when coding for web was really a royal pain. And new browser releases adhere to the specification more and more, which is exactly why the standard matters. It is a kind of theoretical ideal that the browsers will probably never fully achieve, but even 90–95 percent of it are quite useful in the real world.
I also wish IE would have better implementation of CSS, but once You learn the few things that behave oddly, You can code most of the usual layouts without major hiccups. Most common layouts have also been discussed to death on various CSS forums on the web and there is always some good solution readily available so that You do not have to make it up yourself.
The CSS standard is IMHO not the problem [at least not in the sense of Your question], the problem is the reality of the browser market and the software market in general. As for the frustration, it should mostly go away after You gain some experience. The limits will always be there, but there is a plenty of safe space.
That seems like a non-sequitur. Just because some browsers flout web standards does not mean there's something wrong with the standards themselves. It's a bit like saying that seatbelts are broken because some people choose not to wear them, or that drunk driving laws are pointless because some people don't obey them.
If there were absolutely no standards to conform to, then there would be no World Wide Web, period. Just like an egalitarian society is an unachievable ideal, yet striving for that unattainable ideal has produced tremendous social progress over the decades, so too have W3C recommendations and open web standards produced measurable progress over the lifetime of the web. Without standards like CSS, the interoperability which the web depends on to thrive would not exist.
Yes CSS is broken - though semantically you cannot call it a 'broken standard'. But the question is not really one of semantics.
Experience of aiding in the definition of the UNICODE standard back in the late 80s and early 90s was good training for learning how to write a standard well. I have rolled my eyes so many times W3C write standards documentation that leaves immense holes in the definitions that lead to browsers interpreting things in different ways. There are many mutally exclusive parts to the CSS standard, even in v3, that have come about because we still have to keep compatibility with pre-CSS1.
On the critical side, CSS has three mind-bendingly obvious issues that any computer scientist will tell you are both improperly designed and inconsitent.
The Box Model - there are still huge holes in this even as CSS 3 approaches.
The 'specificity' calculations. 'specificity' was implemented to patch a hole in CSS standard and then later to try and shore-up the ever conflicting rules. If stylesheets are be truely cascading then 'specificity' needs to be scrapped. Until it is CSS should be called SWISMCCS (sometimes-when-it-suits-me-CSS). Of course, in order to scrap this feature all the remaining issues with loose language in the standards need fixing - which in reality means it will never happen.
Naming conventions for classes,selector etc allow the use of characters that are a problem for dynamic processing. The most obvious is allowing '-' symbol to be used in names. If you don't understand why I would encourage you to read up and bytecode compilers and compiler language parsing.
So the answer is the CSS standard is not broken, the premise is sound, but the implementation of the standards documentation (not the browsers, the documentation) shows how conquest by committee will rarely get you something fully fit for purpose.
I suppose this was because CSS was not created for trained programmers, it was created for web-designers - a strange breed who are not really programmers and not really designers. There are real web-developers who are different, but spend less time on pretty graphics.
IMHO: CSS is broken. On the other hand, the alternatives are much worse. Better the devil-we-know. Role on the replacement for HTML.