Re: [css-d] links not working smartphone - tablet
Going back to the original “tangent”… Philip did raise a valid point. A site should validate and validation is also a great way to catch the “silly mistakes” we introduce form copying/pasting, typing etc. However, in this age of building sites with bootstrap, jquery plugins we find to help resolve a problem, etc. we introduce (especially css) code into our projects that we did not write. As was so amply demonstrated in this case, many don’t pass validation. I, for one, don’t feel comfortable “correcting” these errors as i(in the case of bootstrap) I’m just coming to grips with responsive site building and don’t wish to modify the underlying “structure” (which I only sort of understand) in case I cause the whole house to fall. I just sort of assume the bootstrap people who coded their css know a lot more than me about css (however, it is surprising that their’s doesn’t validate). What are other’s thoughts/solutions on/for this? Going back to the original problem for a second, the fish in question is making the links on Bob's site work on touch-enabled devices. To catch the fish, I opened the provided URL in Chrome on my laptop with the DOM inspector open. The links worked as expected by default, but when I enabled device emulation to mimic the latest Nexus (a recent smartphone with an associated OS and Chrome variant as its default browser), I noticed the behaviour Bob was talking about. Seeing as the DOM inspector and the viewport showed the link as having been successfully rendered and exhibiting expected default behaviour in at least one instance, I suspected JavaScript: Bob had described the mechanism revealing the links as dependent on hover or touch – hovering has a corresponding CSS state but changing style on touch necessitates scripting. After opening the DOM inspector's 'sources' panel, which deals with JavaScript debugging, I toggled 'pause' [1], which stops JavaScript execution and reveals the line of code which is attempting to execute. This revealed the code block in question, which handles the application of a 'hover' class on touch. But the code was also preventing the default behaviour of that event, which would be to follow the link as expected. Preventing default behaviour is often desirable when JavaScript enhancements replace default functionality, but this isn't one of those cases: we want to apply scripted behaviour regardless of defaults. So by removing the call to `preventDefault`, we let the event take its natural course and expectations are met. So 'validate your markup', as much as it may be good advice, wouldn't have caught this particular fish. In fact, I might assert that 'validate your markup' hasn't taught us anything with regards to this particular problem. The reason people come to this list is usually to seek human insight and communal effort on given problems, which code parsers are unable to give. Conversely, actually reading about Bob's problem, visiting the URL and trying to replicate the behaviour he described proved to be a really good first step to solving the problem. [1]https://developer.chrome.com/devtools/docs/javascript-debugging#sources-panel On 6 Oct 2014 18:07, Karl DeSaulniers k...@designdrumm.com wrote: So in other words. Philip is teaching to fish. Not just giving you a fish. Kudos Philip! Best, Karl Sent from losPhone On Oct 6, 2014, at 5:07 AM, Philip Taylor p.tay...@rhul.ac.uk wrote: Barney Carroll wrote: CSS discuss often reminds me of my doctor, to whom I'll often go with queries about an acute injury and come away with advice to stop smoking – wise well-intentioned, but somewhat short of the assumed benefits in seeking expert advice for a specific problem. But your doctor knows that advising you how to treat an acute pain in your finger caused by an ingrowing nail is unlikely to result in any overall improvement in your condition while you have 252 co-morbities in your arm alone, and four affecting your whole body : http://jigsaw.w3.org/css-validator/validator?uri=http://www.dlp-distribution.fr/ Sorry! We found the following errors (252) http://validator.w3.org/check?uri=http://www.dlp-distribution.fr/ ( errors, now now fixed). It should be a /sine qua non/ to ensure that a given web page validates for both HTML and CSS before asking for help; if Mr Schwartz removes the `e.preventDefault()` invocation on line 22, his page /may/ work as intended on one specific smartphone or tablet today, but it may do something completely unexpected on another device, or tomorrow, or if the wind blows in a different direction, because whilst it is possible to predict the behaviour of valid code with reasonably (but by no means absolute) certainty, it is completely impossible to predict the behaviour of invalid code in any meaningful way at all. Philip Taylor
Re: [css-d] links not working smartphone - tablet
Bootstrap's pragmatic approach deems validity not to be a concern: https://github.com/twbs/bootstrap/issues/6398 In theory, total W3 compliance will make your code behave completely predictably in any environment you care to mention. In practice, popular browsers have deviated from the spec time and time again, with the result of invalid code sometimes being the only way of achieving certain effects in certain browsers. The specifics in Bootstrap's CSS are legacy IE hacks and vendor-prefixed CSS3. Depending on the scope of your expectations, there are often times when something will work in practice but not in theory. A dogmatic purist approach will say that expectations must be revised to match the theory, but I'll always try and find a solution regardless. It's interesting to note that popular frameworks of this ilk (HTML5 boilerplate being another) often fail W3 validation. It's also interesting to tally up the number of times you're faced with tricky problems with regards to web development and code expectations, and W3 validity resolves them. On 7 Oct 2014 07:48, Bob Schwartz b...@fotografics.it wrote: Going back to the original “tangent”… Philip did raise a valid point. A site should validate and validation is also a great way to catch the “silly mistakes” we introduce form copying/pasting, typing etc. However, in this age of building sites with bootstrap, jquery plugins we find to help resolve a problem, etc. we introduce (especially css) code into our projects that we did not write. As was so amply demonstrated in this case, many don’t pass validation. I, for one, don’t feel comfortable “correcting” these errors as i(in the case of bootstrap) I’m just coming to grips with responsive site building and don’t wish to modify the underlying “structure” (which I only sort of understand) in case I cause the whole house to fall. I just sort of assume the bootstrap people who coded their css know a lot more than me about css (however, it is surprising that their’s doesn’t validate). What are other’s thoughts/solutions on/for this? Going back to the original problem for a second, the fish in question is making the links on Bob's site work on touch-enabled devices. To catch the fish, I opened the provided URL in Chrome on my laptop with the DOM inspector open. The links worked as expected by default, but when I enabled device emulation to mimic the latest Nexus (a recent smartphone with an associated OS and Chrome variant as its default browser), I noticed the behaviour Bob was talking about. Seeing as the DOM inspector and the viewport showed the link as having been successfully rendered and exhibiting expected default behaviour in at least one instance, I suspected JavaScript: Bob had described the mechanism revealing the links as dependent on hover or touch – hovering has a corresponding CSS state but changing style on touch necessitates scripting. After opening the DOM inspector's 'sources' panel, which deals with JavaScript debugging, I toggled 'pause' [1], which stops JavaScript execution and reveals the line of code which is attempting to execute. This revealed the code block in question, which handles the application of a 'hover' class on touch. But the code was also preventing the default behaviour of that event, which would be to follow the link as expected. Preventing default behaviour is often desirable when JavaScript enhancements replace default functionality, but this isn't one of those cases: we want to apply scripted behaviour regardless of defaults. So by removing the call to `preventDefault`, we let the event take its natural course and expectations are met. So 'validate your markup', as much as it may be good advice, wouldn't have caught this particular fish. In fact, I might assert that 'validate your markup' hasn't taught us anything with regards to this particular problem. The reason people come to this list is usually to seek human insight and communal effort on given problems, which code parsers are unable to give. Conversely, actually reading about Bob's problem, visiting the URL and trying to replicate the behaviour he described proved to be a really good first step to solving the problem. [1] https://developer.chrome.com/devtools/docs/javascript-debugging#sources-panel On 6 Oct 2014 18:07, Karl DeSaulniers k...@designdrumm.com wrote: So in other words. Philip is teaching to fish. Not just giving you a fish. Kudos Philip! Best, Karl Sent from losPhone On Oct 6, 2014, at 5:07 AM, Philip Taylor p.tay...@rhul.ac.uk wrote: Barney Carroll wrote: CSS discuss often reminds me of my doctor, to whom I'll often go with queries about an acute injury and come away with advice to stop smoking – wise well-intentioned, but somewhat short of the assumed benefits in seeking expert advice for a specific problem. But your doctor knows that advising you how to treat an acute pain in your finger caused by
Re: [css-d] Grid Columns and Frustrations
7 okt 2014 kl. 05:50 skrev Crest Christopher crestchristop...@gmail.com: I want to know, is this the method you use grids or is my starting point completely off the rails ? That really depends on your objective. I don't use a grid framework but use my own basic layouts, that I evolve further in every project, and I do variations on these. More often than not I make an initial specific basic grid for just holding my content and make sure that works and displays as expected in my development platforms (Firefox, Chrome on Android as well as Opera or Safari on IOS), then I build content-out. I always start with the content, believing this is what my design should enhance. Working content-out is the key. This content phase is a point where I've gotten into trouble with clients, because they seldom deliver quality content at the start. So I learnt to get that requirement on them in the signed agreements that also details what ”finished” means allowing for further paid refinements outside of this. I’m not starting development work without one. Nevertheless, content is what it’s all about. Content really is a design problem, so usually I spend time with customers at this stage to develop their content too. Which I charge for naturally. We usually involves use cases, personas and user stories during the development process and many other methods too depending on the project. Then I set the grid for mobile, add media queries so also computers get a basic design. Then I build all pages and functions and gradually work on the design iteratively, with real content in the test site and try different designs. At some point I make design developments in all media queries, slowly bringing them together. I put layouts, typography (including fonts), color in different CSS files (or SCSS) at this stage, so that I can switch at any stage. Later, closer to delivery, I bring them together and minify them all in one file. I use the built-in development tools in Firefox mainly to do the design as well as a the text editor of choice. I make the graphics I need in Fireworks and/or Photoshop. I’ve tried to find a replacement for these, but failed so far. This all means I design in the browser. I make quick sketches on paper to discuss with clients, but these days never in Photoshop. I have an open design process, making the site available for the client as I work, so they can follow the design development. __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] links not working smartphone - tablet
7 okt 2014 kl. 10:16 skrev Barney Carroll barney.carr...@gmail.com: The specifics in Bootstrap's CSS are legacy IE hacks and vendor-prefixed CSS3. Don’t throw out the baby with the bath water. Those are irrelevant errors that you can ignore as you know you’re using vendor-prefixes and IE hacks. That’s not what I referred to when I said it’s a good idea to validate your code. Any web designer worth his/her salt knows what errors to ignore. __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] links not working smartphone - tablet
Barney Carroll wrote: Bootstrap's pragmatic approach deems validity not to be a concern: https://github.com/twbs/bootstrap/issues/6398 I am afraid that mdo does not understand the concept of validity. He (or she) writes : All the CSS we use is valid, and while some lines are hacks (* for IE7, \9 for IE7-9, etc), it all renders as expected. The first part of the assertion is demonstrably false (the CSS is patently invalid) and it all renders as expected has nothing to do with validity whatsoever. It is a pragmatic value judgment made on the basis of tests using browsers known to, and available to, the author, as those browsers were at the time that the tests were conducted. It says nothing whatsoever about browsers with which he or she was unfamiliar, or were not available to him/'her, nothing about how it performs in the same browsers today (or will behave tomorrow) and even less about validity. And as Edsger Dijkstra reminded us over 40 years ago : Testing can reveal only the presence of bugs, not their absence [1]. Philip Taylor [1] Dijkstra (1970) Notes On Structured Programming (EWD249), Section 3 (On The Reliability of Mechanisms), corollary at the end. __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
[css-d] custom fonts not working in Chrome
Hi list, I made a new website in which I used custom fonts. It works in Firefox, Opera and IE, but in Chrome the fonts default to the standard webfont. Not sure if I'm missing something. Website: http://www.reconnectdiscover.com CSS: http://www.reconnectdiscover.com/css/styles.css Any pointers would be greatly appreciated! Arno __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] custom fonts not working in Chrome
Might be your @font-face. Try this: http://www.fontspring.com/blog/the-new-bulletproof-font-face-syntax On Tuesday, October 7, 2014, Stuff @ arnoenzerink.com st...@arnoenzerink.com wrote: Hi list, I made a new website in which I used custom fonts. It works in Firefox, Opera and IE, but in Chrome the fonts default to the standard webfont. Not sure if I'm missing something. Website: http://www.reconnectdiscover.com CSS: http://www.reconnectdiscover.com/css/styles.css Any pointers would be greatly appreciated! Arno __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/ -- Tom Livingston | Senior Front-End Developer | Media Logic | ph: 518.456.3015x231 | fx: 518.456.4279 | mlinc.com __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] links not working smartphone - tablet
Yeah, the impression I get it is that they're not really concerned about CSS validity. They do care about HTML validity, though – they use an automated validation reporter (no more having to open email, scan email for URL, paste URL into validator, copy link into email reply, hit send) for their issue tracker: https://github.com/cvrebert/lmvtfy Karl brought up (or rather, implied) a good point earlier, which is show your workings (teach a man how to fish was the analogy he used), and obviously even the automated solution used by Bootstrap needs someone to perceive and report an error before validation occurs, which is still too late (or rather, relies on failure preceding success). A recent article on the Zurb blog [1] makes a sensationalist claim that the W3 validator has outlived its usefulness. What they're getting at is that what they perceive to be the 'modern' development environment involves tools that can check for these issues before they become problems. They're still pretty thin on details, but for Sublime Text [2] fans, I can recommend the SublimeLinter [3], which is a highly configurable tool for linting code as you go. I use the JSHint plugin exclusively, but for those that care there is an HTML tidy plugin which will highlight validation errors in a manner of your choosing as you type them. If you want to be rigorous, using a tool like this could prevent you from ever even saving an invalid file. [1] http://zurb.com/article/1260/we-ve-moved-beyond-code-validators [2] http://www.sublimetext.com/ [3] http://www.sublimelinter.com/ It says nothing whatsoever about browsers with which he or she was unfamiliar, or were not available to him/'her, nothing about how it performs in the same browsers today (or will behave tomorrow) and even less about validity. It's gratifying to have validity marked out as a distinct concern as compared to those other issues. Bootstrap browser support is dependent on version and documented: http://bootstrapdocs.com/v1.1.0/docs/#about Regarding problems that may occur on other days, with other browsers, they do have other issues (that was number 6398) and the general public are free to report issues as they crop up. So there's at least a method for dealing with problems and a proven track record of enacting it. It says nothing whatsoever about browsers with which he or she was unfamiliar This begs the question: how much should one expound on browsers that one is unfamiliar with, in general? __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] links not working smartphone - tablet
Barney Carroll wrote: This begs the question: how much should one expound on browsers that one is unfamiliar with, in general? One should not expound on them at all : one should simply state Our HTML and CSS are W3C-compliant and W3C-validated, and, as far as we are aware, render correctly in all browsers that are themselves W3C-compliant. If they do not render as you would wish in the browser of your choice, please draw this to our attention. We take great pride in the material we produce, but if it renders correctly in browsers that are themselves W3C-compliant, we are unlikely to expend major effort in also making it render appropriately in less-compliant browsers -- you may do better to contact your browser vendor directly and ask them to investigate the rendering issues you have reported. Philip Taylor __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] links not working smartphone - tablet
you may do better to contact your browser vendor directly and ask them to investigate the rendering issues you have reported I'm wondering how differently my career might have worked out if all those times IE came up I'd just told the client to get onto Bill Gates about it. Maybe I'm just a sucker for punishment ;) Regards, Barney Carroll barney.carr...@gmail.com +44 7429 177278 barneycarroll.com On 7 October 2014 12:48, Philip Taylor p.tay...@rhul.ac.uk wrote: Barney Carroll wrote: This begs the question: how much should one expound on browsers that one is unfamiliar with, in general? One should not expound on them at all : one should simply state Our HTML and CSS are W3C-compliant and W3C-validated, and, as far as we are aware, render correctly in all browsers that are themselves W3C-compliant. If they do not render as you would wish in the browser of your choice, please draw this to our attention. We take great pride in the material we produce, but if it renders correctly in browsers that are themselves W3C-compliant, we are unlikely to expend major effort in also making it render appropriately in less-compliant browsers -- you may do better to contact your browser vendor directly and ask them to investigate the rendering issues you have reported. Philip Taylor __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
[css-d] OT : links not working smartphone - tablet
Barney Carroll wrote: I'm wondering how differently my career might have worked out if all those times IE came up I'd just told the client to get onto Bill Gates about it. If /every/ W3C-compliant web site had carried that text, the world might now be a very different (and much better) place ... I love Windows (7), completely fail to understand the masochistic appeal of *X, but nonetheless deeply wish that Mr Gates (and Mr Google, and all the rest of the Big Boys) cared more about complying to standards and less about seeking to define them. This guy identifies many of the problems in a nuthell : http://www.sitepoint.com/w3c-css-webkit-prefix-crisis/ Philip Taylor __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] custom fonts not working in Chrome
Le 7 oct. 2014 à 20:28, Stuff @ arnoenzerink.com st...@arnoenzerink.com a
écrit :
I made a new website in which I used custom fonts.
It works in Firefox, Opera and IE, but in Chrome the fonts default to the
standard webfont.
Not sure if I'm missing something.
Website: http://www.reconnectdiscover.com
CSS: http://www.reconnectdiscover.com/css/styles.css
No custom fonts in Safari / Firefox / Opera here (using Helvetica everywhere).
Are you sure the fonts are where your stylesheet is pointing to?
The browsers are looking for the fonts in
http://www.reconnectdiscover.com/css/css/GOTHMBOL.TTF
Note the double occurrence of 'css' in the path.
(on your server, they actually are at:
http://www.reconnectdiscover.com/css/GOTHMBOL.TTF
Note: one occurrence of 'css' in the path)
You'll need to change the URL in your @font-face blocks, like this:
@font-face {
font-family: Gotham-Book;
src: url(css/GOTHMBOK.TTF); /* IE */
src: local('Gotham-Book'), url('GOTHMBOK.TTF') format('truetype'); /* others
*/
}
BTW consider converting your fonts to WOFF, it will save you tons on download
speed:
http://www.fontsquirrel.com/fontface/generator
Philippe
--
Philippe Wittenbergh
http://l-c-n.com/
__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] OT : links not working smartphone - tablet
IE and Mozilla have now committed to supporting -webkit- prefixed properties. The obvious problem is that the W3C is too slow and cumbersome for many people's desires and expectations of the web. IE6 came with a suite of incredibly powerful functionality that the rest of browser-land is only now catching up to (filter: anyone?). The problem then was that some of the earliest webapps were designed specifically for IE, back when there was no conceivable way of forking the code to achieve similar functionality in other browsers. VML was submitted 2 years before SVG started taking shape. IE6's lofty goals were almost reinstated in the HTML5 in the broadest sense that the W3 tried to make a PR splash about (embedded multimedia, file-system API, seamless vector graphics in HTML, CSS3 transforms filters). But once again, people have come to expect awesome stuff that the W3C is too slow to ratify to a universal consensus. So the responsibility (which, I agree, ultimately rests on website authors) comes down to managing expectations. It's tough to say no, especially when there's a lot of money in it and many people in the trade of web development are inclined to exploratory hacking anyway. It's becoming increasingly more difficult to tell people you can't, in good conscience, serve up code relying on unratified specifications, when implementation of such functionality is ubiquitous (and you know how to do it). A few years ago web development studios started finding the willpower to tell clients they wouldn't commit to like-for-like experiences in legacy Internet Explorer versions, and for a while standards-compliance seemed to be that bit more tenable – but recently I've come across numerous situations where people will say they only care about Chrome iOS support. As regards the 'reasonableness' of these various expectations, I think W3C compliant validity is at its most applicable when it comes to web sites consisting of many documents: you want these documents to be consistent with each-other and marked up to universal standards for reasons of posterity universal access. For my part, what I've been working on for the better part of the last year would be more accurately described as web apps: there's a single HTML document and it acts more as a wrapper for dynamic functionality. The term 'document' barely applies, and the use-cases are so esoteric and business-critical that the client will happily use a specific browser version in order to guarantee expected behaviour. Regards, Barney Carroll barney.carr...@gmail.com +44 7429 177278 barneycarroll.com On 7 October 2014 13:53, Philip Taylor p.tay...@rhul.ac.uk wrote: Barney Carroll wrote: I'm wondering how differently my career might have worked out if all those times IE came up I'd just told the client to get onto Bill Gates about it. If /every/ W3C-compliant web site had carried that text, the world might now be a very different (and much better) place ... I love Windows (7), completely fail to understand the masochistic appeal of *X, but nonetheless deeply wish that Mr Gates (and Mr Google, and all the rest of the Big Boys) cared more about complying to standards and less about seeking to define them. This guy identifies many of the problems in a nuthell : http://www.sitepoint.com/w3c-css-webkit-prefix-crisis/ Philip Taylor __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] OT : links not working smartphone - tablet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/07/2014 03:23 PM, Barney Carroll wrote: IE and Mozilla have now committed to supporting -webkit- prefixed properties. Do you have a citation for the Mozilla commitment? Last time I checked, we decided against it. Ms2ger -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJUM/AMAAoJEOXgvIL+s8n23qEH/iol1pJ/ClW41JEiy8W/cjYS mI3XgKmAt52elEh9+2jCxstwvcBYwV2GDHfGE/EB1asFRK739yKMw8Y/yQan9pPN ju9ZfSwGzQipWwSC7Fr/AoIEPyloabx/AezeSacbNFDyFDiOLAuPq3b1tgFmNKEl UNC9igNOw8ltUKff9ozWl0Eiao1NMuDQRS7c4FbL4gGUgMcwaOWUy6XZifd5gH6a hhxK14BoY0pjEjnbiAbZPZ9X9ih2IDhIWNATa0H4zC/YstdSORqvAvltzOt4Y4vv 75VOlDlSVtJC3s8dltaKg7M6KHRlkP4f05FKtj4c3VFBLbIPgzjhg5offUfLH3s= =8f68 -END PGP SIGNATURE- __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] OT : links not working smartphone - tablet
Oops! Sorry Ms2ger, good save. Was going off an aside Tantek made in a working group meeting in February 2012 [1] when he said Zero [webkit-prefixed properties] is no longer an option for us . I didn't read up to realize that the resolution in Gecko policy was to actively work at removing all prefixed properties from the application lifecycle altogether. Thanks for prompting! [1] http://lists.w3.org/Archives/Public/www-style/2012Feb/0313.html On 7 Oct 2014 14:52, Ms2ger ms2...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/07/2014 03:23 PM, Barney Carroll wrote: IE and Mozilla have now committed to supporting -webkit- prefixed properties. Do you have a citation for the Mozilla commitment? Last time I checked, we decided against it. Ms2ger -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJUM/AMAAoJEOXgvIL+s8n23qEH/iol1pJ/ClW41JEiy8W/cjYS mI3XgKmAt52elEh9+2jCxstwvcBYwV2GDHfGE/EB1asFRK739yKMw8Y/yQan9pPN ju9ZfSwGzQipWwSC7Fr/AoIEPyloabx/AezeSacbNFDyFDiOLAuPq3b1tgFmNKEl UNC9igNOw8ltUKff9ozWl0Eiao1NMuDQRS7c4FbL4gGUgMcwaOWUy6XZifd5gH6a hhxK14BoY0pjEjnbiAbZPZ9X9ih2IDhIWNATa0H4zC/YstdSORqvAvltzOt4Y4vv 75VOlDlSVtJC3s8dltaKg7M6KHRlkP4f05FKtj4c3VFBLbIPgzjhg5offUfLH3s= =8f68 -END PGP SIGNATURE- __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/ __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Grid Columns and Frustrations
Do you mean, will this site be displayed on mobile ? Philip Taylor mailto:p.tay...@rhul.ac.uk Tuesday, October 07, 2014 2:24 AM What is its behaviour intended to be, Christopher, when the browser window is less than 960 px wide ? Philip Taylor Crest Christopher mailto:crestchristop...@gmail.com Monday, October 06, 2014 11:50 PM I created a starting point of a quasi web site, if I was using the 960 grid system, as an example. I placed two divs on the page. I want to know, is this the method you use grids or is my starting point completely off the rails ? [Link http://www.thecreativesheep.ca/webdesignprojects/smallprojects/demo_24_col.html] MiB mailto:digital.disc...@gmail.com Monday, October 06, 2014 3:54 PM Side-note: It’s useful to know what’s possible, but we all still have to do one page design at a time to really make it possible. Anything’s possible more or less. The real questions are commonly more like what’s needed?, what answers the objectives set up? and what looks irresistable when it’s on the web in any (target) browser on any (target) device? and similar. __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/ Crest Christopher mailto:crestchristop...@gmail.com Monday, October 06, 2014 1:18 AM I was throwing random ideologies that exist as questions. The basis of CSS I know, I may not have it all memorized but I know what is possible, if it's advanced css, I may be rusty, but once again, I know what is possible. You don't need a grid frame work, obviously, although if you want to build a responsive site they say it will help with the development. As for flaky web development information on the web, yes there is obviously way to much online, IMO you have to wipe all of that off the table and learn the foundation, then for all other questions that are present, there is none other then, for example, this mailing list ! MiB mailto:digital.disc...@gmail.com Sunday, October 05, 2014 12:44 PM 3 okt 2014 kl. 02:31 skrev Crest Christophercrestchristop...@gmail.com: you cut up your graphics You don’t. You do sprites or use CSs. and now how do you translate the design from the PSD to your grid, You don’t translate. You use PS for creating some graphics and perhaps treating photos. You design in the browser. Or in yuor head. o you get an exact representation of your site whether it's a responsive site or not You don’t an exact representation” of something. You build a web site. Let go of the 90’s and even the 00’s. It’s over. __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/ __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] (no subject)
Help! I am not subscribed - these emails started coming at random - how do I unsubscribe? John E. Cavanaugh MD. There's always a wrong way to do the right thing ... Cavanaugh's Law On Oct 7, 2014, at 8:23, Barney Carroll barney.carr...@gmail.com wrote: IE and Mozilla have now committed to supporting -webkit- prefixed properties. The obvious problem is that the W3C is too slow and cumbersome for many people's desires and expectations of the web. IE6 came with a suite of incredibly powerful functionality that the rest of browser-land is only now catching up to (filter: anyone?). The problem then was that some of the earliest webapps were designed specifically for IE, back when there was no conceivable way of forking the code to achieve similar functionality in other browsers. VML was submitted 2 years before SVG started taking shape. IE6's lofty goals were almost reinstated in the HTML5 in the broadest sense that the W3 tried to make a PR splash about (embedded multimedia, file-system API, seamless vector graphics in HTML, CSS3 transforms filters). But once again, people have come to expect awesome stuff that the W3C is too slow to ratify to a universal consensus. So the responsibility (which, I agree, ultimately rests on website authors) comes down to managing expectations. It's tough to say no, especially when there's a lot of money in it and many people in the trade of web development are inclined to exploratory hacking anyway. It's becoming increasingly more difficult to tell people you can't, in good conscience, serve up code relying on unratified specifications, when implementation of such functionality is ubiquitous (and you know how to do it). A few years ago web development studios started finding the willpower to tell clients they wouldn't commit to like-for-like experiences in legacy Internet Explorer versions, and for a while standards-compliance seemed to be that bit more tenable – but recently I've come across numerous situations where people will say they only care about Chrome iOS support. As regards the 'reasonableness' of these various expectations, I think W3C compliant validity is at its most applicable when it comes to web sites consisting of many documents: you want these documents to be consistent with each-other and marked up to universal standards for reasons of posterity universal access. For my part, what I've been working on for the better part of the last year would be more accurately described as web apps: there's a single HTML document and it acts more as a wrapper for dynamic functionality. The term 'document' barely applies, and the use-cases are so esoteric and business-critical that the client will happily use a specific browser version in order to guarantee expected behaviour. Regards, Barney Carroll barney.carr...@gmail.com +44 7429 177278 barneycarroll.com On 7 October 2014 13:53, Philip Taylor p.tay...@rhul.ac.uk wrote: Barney Carroll wrote: I'm wondering how differently my career might have worked out if all those times IE came up I'd just told the client to get onto Bill Gates about it. If /every/ W3C-compliant web site had carried that text, the world might now be a very different (and much better) place ... I love Windows (7), completely fail to understand the masochistic appeal of *X, but nonetheless deeply wish that Mr Gates (and Mr Google, and all the rest of the Big Boys) cared more about complying to standards and less about seeking to define them. This guy identifies many of the problems in a nuthell : http://www.sitepoint.com/w3c-css-webkit-prefix-crisis/ Philip Taylor __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/ __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Grid Columns and Frustrations
MiB your message seems to go into your development process rather then on grids and columns and understanding them ! MiB mailto:digital.disc...@gmail.com Tuesday, October 07, 2014 4:52 AM That really depends on your objective. I don't use a grid framework but use my own basic layouts, that I evolve further in every project, and I do variations on these. More often than not I make an initial specific basic grid for just holding my content and make sure that works and displays as expected in my development platforms (Firefox, Chrome on Android as well as Opera or Safari on IOS), then I build content-out. I always start with the content, believing this is what my design should enhance. Working content-out is the key. This content phase is a point where I've gotten into trouble with clients, because they seldom deliver quality content at the start. So I learnt to get that requirement on them in the signed agreements that also details what ”finished” means allowing for further paid refinements outside of this. I’m not starting development work without one. Nevertheless, content is what it’s all about. Content really is a design problem, so usually I spend time with customers at this stage to develop their content too. Which I charge for naturally. We usually involves use cases, personas and user stories during the development process and many other methods too depending on the project. Then I set the grid for mobile, add media queries so also computers get a basic design. Then I build all pages and functions and gradually work on the design iteratively, with real content in the test site and try different designs. At some point I make design developments in all media queries, slowly bringing them together. I put layouts, typography (including fonts), color in different CSS files (or SCSS) at this stage, so that I can switch at any stage. Later, closer to delivery, I bring them together and minify them all in one file. I use the built-in development tools in Firefox mainly to do the design as well as a the text editor of choice. I make the graphics I need in Fireworks and/or Photoshop. I’ve tried to find a replacement for these, but failed so far. This all means I design in the browser. I make quick sketches on paper to discuss with clients, but these days never in Photoshop. I have an open design process, making the site available for the client as I work, so they can follow the design development. __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/ Crest Christopher mailto:crestchristop...@gmail.com Monday, October 06, 2014 11:50 PM I created a starting point of a quasi web site, if I was using the 960 grid system, as an example. I placed two divs on the page. I want to know, is this the method you use grids or is my starting point completely off the rails ? [Link http://www.thecreativesheep.ca/webdesignprojects/smallprojects/demo_24_col.html] MiB mailto:digital.disc...@gmail.com Monday, October 06, 2014 3:54 PM Side-note: It’s useful to know what’s possible, but we all still have to do one page design at a time to really make it possible. Anything’s possible more or less. The real questions are commonly more like what’s needed?, what answers the objectives set up? and what looks irresistable when it’s on the web in any (target) browser on any (target) device? and similar. __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/ Crest Christopher mailto:crestchristop...@gmail.com Monday, October 06, 2014 1:18 AM I was throwing random ideologies that exist as questions. The basis of CSS I know, I may not have it all memorized but I know what is possible, if it's advanced css, I may be rusty, but once again, I know what is possible. You don't need a grid frame work, obviously, although if you want to build a responsive site they say it will help with the development. As for flaky web development information on the web, yes there is obviously way to much online, IMO you have to wipe all of that off the table and learn the foundation, then for all other questions that are present, there is none other then, for example, this mailing list ! MiB mailto:digital.disc...@gmail.com Sunday, October 05, 2014 12:44 PM 3 okt 2014 kl. 02:31 skrev Crest Christophercrestchristop...@gmail.com: you cut up your graphics You don’t. You do sprites or use CSs. and now how do you translate the design from
Re: [css-d] Grid Columns and Frustrations
Crest Christopher wrote: Do you mean, will this site be displayed on mobile ? No, I mean exactly what I said : what is your intended behaviour if the page is displayed in a browser window that is narrower than 960px ? __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Grid Columns and Frustrations
7 okt 2014 kl. 16:18 skrev Crest Christopher crestchristop...@gmail.com: MiB your message seems to go into your development process rather then on grids and columns and understanding them ! It does. My apologies. It should be clear though my grids are always different when the content is different. To me a grid” is chosen specifically based on the actual content. In short my grids are just simple width divisions and height divisions based on font size and readability decisions. Your original question concerned grid frameworks didn’t it? I tried to explain that instead of a grid framework I use a process in how I build my grid-based designs. This could of course involve a grid framework as these are normally flexible on what grid they can build. I don’t use them. Maybe what you want to know is more about how to apply a specific grid in a specific framework? __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] custom fonts not working in Chrome
Arno, You need to load more than just .TTF files. Take a look at this page from CSS Tricks it's more up to date. Eric http://css-tricks.com/snippets/css/using-font-face/ On October 7, 2014 at 7:28 AM Stuff @ arnoenzerink.com st...@arnoenzerink.com wrote: Hi list, I made a new website in which I used custom fonts. It works in Firefox, Opera and IE, but in Chrome the fonts default to the standard webfont. Not sure if I'm missing something. Website: http://www.reconnectdiscover.com CSS: http://www.reconnectdiscover.com/css/styles.css Any pointers would be greatly appreciated! Arno __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/ __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Grid Columns and Frustrations
Using the link I provided as a base, I want to know is the route that I have taken correct in building and a site and using a grid framework ? Most frameworks include a school of divs and a school of classes in the style sheet, this is why I want to know is the starting method I took, the right path in using a grid frame work ? MiB - Do you have any of your grids to show ? MiB mailto:digital.disc...@gmail.com Tuesday, October 07, 2014 11:55 AM It does. My apologies. It should be clear though my grids are always different when the content is different. To me a grid” is chosen specifically based on the actual content. In short my grids are just simple width divisions and height divisions based on font size and readability decisions. Your original question concerned grid frameworks didn’t it? I tried to explain that instead of a grid framework I use a process in how I build my grid-based designs. This could of course involve a grid framework as these are normally flexible on what grid they can build. I don’t use them. Maybe what you want to know is more about how to apply a specific grid in a specific framework? __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/ Crest Christopher mailto:crestchristop...@gmail.com Tuesday, October 07, 2014 10:18 AM MiB your message seems to go into your development process rather then on grids and columns and understanding them ! MiB mailto:digital.disc...@gmail.com Tuesday, October 07, 2014 4:52 AM That really depends on your objective. I don't use a grid framework but use my own basic layouts, that I evolve further in every project, and I do variations on these. More often than not I make an initial specific basic grid for just holding my content and make sure that works and displays as expected in my development platforms (Firefox, Chrome on Android as well as Opera or Safari on IOS), then I build content-out. I always start with the content, believing this is what my design should enhance. Working content-out is the key. This content phase is a point where I've gotten into trouble with clients, because they seldom deliver quality content at the start. So I learnt to get that requirement on them in the signed agreements that also details what ”finished” means allowing for further paid refinements outside of this. I’m not starting development work without one. Nevertheless, content is what it’s all about. Content really is a design problem, so usually I spend time with customers at this stage to develop their content too. Which I charge for naturally. We usually involves use cases, personas and user stories during the development process and many other methods too depending on the project. Then I set the grid for mobile, add media queries so also computers get a basic design. Then I build all pages and functions and gradually work on the design iteratively, with real content in the test site and try different designs. At some point I make design developments in all media queries, slowly bringing them together. I put layouts, typography (including fonts), color in different CSS files (or SCSS) at this stage, so that I can switch at any stage. Later, closer to delivery, I bring them together and minify them all in one file. I use the built-in development tools in Firefox mainly to do the design as well as a the text editor of choice. I make the graphics I need in Fireworks and/or Photoshop. I’ve tried to find a replacement for these, but failed so far. This all means I design in the browser. I make quick sketches on paper to discuss with clients, but these days never in Photoshop. I have an open design process, making the site available for the client as I work, so they can follow the design development. __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/ Crest Christopher mailto:crestchristop...@gmail.com Monday, October 06, 2014 11:50 PM I created a starting point of a quasi web site, if I was using the 960 grid system, as an example. I placed two divs on the page. I want to know, is this the method you use grids or is my starting point completely off the rails ? [Link http://www.thecreativesheep.ca/webdesignprojects/smallprojects/demo_24_col.html] MiB mailto:digital.disc...@gmail.com Monday, October 06, 2014 3:54 PM Side-note: It’s useful to know what’s possible, but we all still have to do one page design at a time to really make it
Re: [css-d] Grid Columns and Frustrations
Would anyone be willing to create a video on when they are using a grid frame work how they begin, up to atleast half way of the development process ? Philip Taylor mailto:p.tay...@rhul.ac.uk Tuesday, October 07, 2014 10:20 AM Crest Christopher wrote: No, I mean exactly what I said : what is your intended behaviour if the page is displayed in a browser window that is narrower than 960px ? Crest Christopher mailto:crestchristop...@gmail.com Tuesday, October 07, 2014 10:16 AM Do you mean, will this site be displayed on mobile ? Philip Taylor mailto:p.tay...@rhul.ac.uk Tuesday, October 07, 2014 2:24 AM What is its behaviour intended to be, Christopher, when the browser window is less than 960 px wide ? Philip Taylor Crest Christopher mailto:crestchristop...@gmail.com Monday, October 06, 2014 11:50 PM I created a starting point of a quasi web site, if I was using the 960 grid system, as an example. I placed two divs on the page. I want to know, is this the method you use grids or is my starting point completely off the rails ? [Link http://www.thecreativesheep.ca/webdesignprojects/smallprojects/demo_24_col.html] MiB mailto:digital.disc...@gmail.com Monday, October 06, 2014 3:54 PM Side-note: It’s useful to know what’s possible, but we all still have to do one page design at a time to really make it possible. Anything’s possible more or less. The real questions are commonly more like what’s needed?, what answers the objectives set up? and what looks irresistable when it’s on the web in any (target) browser on any (target) device? and similar. __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/ __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
[css-d] History and other points of interest Re: OT : links not working smartphone - tablet
Boy, am I ever late to this party. Even so, my mind's been on these
things today, so I'm writing.
Also, I apologize for the threading. I inadvertently sent this to Mr.
Carroll rather than the list, and if T-Bird has a secret handshake for
resolving that contingency, I don't know what it is.
TL;DR: It's all about good habits. Always was, always will be, and
always leading to more site for less money when practiced by people
whose skills are not in question.
On 10/7/14, 6:23 AM, Barney Carroll wrote:
The obvious problem is that the W3C is too slow and cumbersome for
many people's desires and expectations of the web. IE6 came with a
[...And IE5.x before it...]
suite of incredibly powerful functionality that the rest of
browser-land is only now catching up to (filter: anyone?). The
Cf. alpha, animation, gradient c. support per the CSS3 module specs.
Many of these are actually well-supported in current-gen browsers.
Alpha in basic forms has enjoyed reliable support for something close to
ten years; I first used it in a production project during June 2006.
The semanticians, and some few standardistas who don't participate here,
are in the final stages of a quiet, intermittent battle over the
proposition thatr filter:foo() and expression() are at all appropriate
to include in the CSS context. To further confuse matters, jQuery and
the various groups flogging their preferred preprocessors have jumped in
with their own approaches to implementation.
problem then was that some of the earliest webapps were designed
specifically for IE, back when there was no conceivable way of
forking the code to achieve similar functionality in other browsers.
...It's been practical to fork JavaScript out to the barest limits from
the moment both Netscape 4 and IE 3.01 came out.
Having successfully met it, however, I would not wish on anyone the
requirement to support IE 4-5 and Netscape 4 comparably. Among other
things, the whack approach to the box model in all of them requires what
we call a polyfill... these days.
VML was submitted 2 years before SVG started taking shape. IE6's
lofty goals were almost reinstated in the HTML5 in the broadest
sense that the W3 tried to make a PR splash about (embedded
multimedia, file-system API, seamless vector graphics in HTML, CSS3
transforms filters). But once again, people have come to expect
awesome stuff that the W3C is too slow to ratify to a universal
consensus.
People, for the most part, DO NOT CARE.
They only care when something that works in {x} breaks in {y}, and damn
the contract language, even if {y} happens to be a beige box PC from a
practically anonymous vendor running Win98SE to a lousy display.
(16-bit color spaces, anyone?)
Salespeople and ubernerds care VERY, VERY MUCH. Of course, both of
those groups tend to think of things like support gaps as obstacles to
be scaled by McGyverish means if necessary, not as limitations that will
work themselves out in the face of patience and persistence. I'd gander
that one hour of thoughtful lobbying to (or chain-yanking of) someone in
a position to Do Something is probably worth several THOUSAND hours of
engineering workarounds.
[Cf. the Browser Upgrade Campaign in 2005, for which the Web Standards
Project set the stage - and in which, therefore, I played a VERY
peripheral part - before the IE product team sent us word that they'd be
willing to listen to us, but only if we divested the campaign.]
Just don't tell that to the salespeople and ubernerds.
...And this is where I point out that I'm writing here because I was
just thinking about this today: every HTML spec from 2.0 through to
4.01 was mostly retrospective. [CSS2, and ESPECIALLY CSS2.1, also
shoulder this burden.]
* 2.0 added forms and images;
* 3.2 added anonymous elements (div, span),
bidi links, and tables; and
* 4.x added event handlers and the table extensions
that had come about in the meantime.
There *is* an HTML3.0, as well; that never made it past the Proposed
milestone (if even that far) because its development was integral with
backchannel discussions that involved Dave Raggett and commercial
browser engineers, a fact that we could only apprehend in hindsight.
HTML5 was developed on terms that reflected appreciation of the process
mistakes committed with HTML3.0.
To HTML4's credit, it turned a11y into an Official Thing with equally
official API features, which it hadn't really been until then.
So the responsibility (which, I agree, ultimately rests on website
authors) comes down to managing expectations. It's tough to say no,
especially when there's a lot of money in it and many people in the
trade of web development are inclined to exploratory hacking anyway.
Yes, that's a good deal more delicately put than my version.
It's becoming increasingly more difficult to tell people you can't,
in good conscience, serve up code relying on unratified
specifications, when implementation of such functionality is
ubiquitous (and
