| 01:10 | <Hixie> | ok how on earth do i spec <fieldset> |
| 01:25 | <jcranmer> | Hixie: simple |
| 01:25 | <jcranmer> | "the specifics of this element are left undefined" |
| 01:26 | <jcranmer> | "all browsers must render this element in accord with the Mosaic Browser, build <what is the build date of Mosaic?>" |
| 01:29 | <othermaciej> | does anyone still use <fieldset>? |
| 01:29 | <othermaciej> | maybe my view is colored by using a Mac, where you pretty much never would use the equivalent control in a dialog these days |
| 01:29 | <othermaciej> | but I don't think I see it much in web UI either |
| 01:31 | jwalden_ | has (gratuitously?) used it once or twice |
| 01:35 | <Hixie> | jcranmer: the whole point of this section is to not do that :-P |
| 01:36 | <Hixie> | othermaciej: are you willing to drop support? if not, then i want to spec it. :-) |
| 01:36 | Hixie | does <hr> instead |
| 01:37 | <othermaciej> | Hixie: oh, I'm sure its behavior needs to be specified |
| 01:37 | <othermaciej> | Hixie: and probably people would complain if it were to be made nonconforming |
| 01:37 | <Hixie> | people complain about _anything_ we make non-conforming |
| 01:37 | <othermaciej> | but all that being said, it still seems obsolete for modern Web development |
| 01:37 | <Hixie> | (people have even complained about <meta scheme=""> being made non-conforming) |
| 01:55 | <Hixie> | wow, the default styles for <fieldset> in IE8 are terrible |
| 02:38 | <sayrer> | Hixie, othermaciej, people still use fieldset |
| 02:39 | <sayrer> | I last saw it generated by mailchimp.com's signup forms |
| 02:39 | <othermaciej> | I know it is used at more than trivial frequency |
| 02:39 | <othermaciej> | it definitely needs to be implemented to have a browser that is compatible with the Web |
| 02:40 | <othermaciej> | but probably new content should be discouraged from using it, since it is based on dated ideas of HI design |
| 02:45 | <sayrer> | I just added a fieldset to my last blog post |
| 02:45 | <sayrer> | it made a box |
| 02:46 | <sayrer> | but the lines didn't touch |
| 02:46 | <sayrer> | nice |
| 08:48 | <annevk> | ooh, design principles discussion |
| 08:48 | <annevk> | I was hoping to not edit that document any further |
| 08:52 | <Lachy> | annevk, it would be nice to get it published at some point |
| 08:59 | <annevk> | it is published |
| 09:03 | <Lachy> | I mean finished |
| 09:06 | <annevk> | how would that help? |
| 09:14 | <othermaciej> | annevk: I don't see anyone really asking to change it or debating the contents |
| 09:15 | <othermaciej> | (except for I guess the vaguely proposed Baby Steps and Build from Justification principles) |
| 09:15 | <annevk> | yeah, oh well, I just deleted the e-mails :) |
| 09:28 | jgraham | in unfamiliar with this concerpt of delete as applied to eamils |
| 09:28 | <jgraham> | wow, that was even worse typing than usual |
| 09:38 | <zcorpan> | othermaciej: i thought <fieldset> was helpful for people with ATs to navigate in forms, but maybe <h1>-<h6> that are descendants of forms could be a good-enough replacement? |
| 09:44 | jgraham | has a tendency to use fieldset even though it looks pretty ugly for maybe-cargo-cult reasons |
| 09:46 | <hsivonen> | Validator.nu uses fieldset |
| 09:47 | <jgraham> | http://www.paciellogroup.com/blog/?p=3 talks about fieldset. The JAWS 8 UI for it seems pretty miserable to me |
| 09:48 | <jgraham> | http://www.rnib.org.uk/wacblog/articles/too-much-accessibility/too-much-accessibility-fieldset-legends/ |
| 09:48 | <jgraham> | It sounds increasingly like <fieldset> causes more problems than it solves |
| 09:49 | <jgraham> | (at least in some random version of JAWS) |
| 09:54 | <zcorpan> | it's interesting how people's reaction to weird behavior in software often is "change our habits to make the behavior appear less weird" instead of "contact the vendor and make them fix their weird behavior" |
| 09:55 | <annevk> | they're not QA, they want to make things work now |
| 09:56 | <jgraham> | zcorpan: Presumably they see changing their behaviour as something simple and easilly achievable whereas changing the software is hard |
| 09:56 | <annevk> | this might be were some of the clashes on public-html are coming from |
| 09:57 | <jgraham> | Or they percieve (especially on "moral" issues like accessibility) that the "experts" who write the software are right and it is they who is making the mistake |
| 09:57 | <hsivonen> | see also internationalization :-( |
| 10:04 | <jgraham> | In the specific case of accessibility software, everytime anyone suggests changing the software, someone says that that is useless since the actual end users can't afford new versions anyway and hard since the vendors are difficult to contact |
| 10:08 | <hsivonen> | jgraham: did you see the unicode normalization thread that revolves around some text input methods failing to canonically reorder combining marks if keystrokes aren't in the canonical order? |
| 10:09 | <hsivonen> | despite Japanese input methods everywhere and OS X European input methods performing more complex tricks |
| 10:09 | <jgraham> | hsivonen: I think I saw part of the thread but not that part |
| 10:09 | <jgraham> | (maybe not the start if that was the start) |
| 10:32 | <BenMillard> | jgraham, what seemed "miserable" about the JAWS UI for <fieldset>+<legend>? |
| 10:34 | <BenMillard> | zcorpan, headings in forms make sense but rarely happen, from what I've seen. They wouldn't need special treatment when the heading level is chosen sensibly by the author. |
| 10:36 | <BenMillard> | othermaciej, what is so dated about <fieldset><legend> that it should be discouraged? Just the way it looks or something deeper? |
| 10:36 | Philip` | has used <fieldset><legend><input type=checkbox onclick=toggle(fields)> Stuff</legend><div id=fields>...forms fields...</div></fieldset> and thinks it works reasonably nicely |
| 10:36 | <jgraham> | BenMillard: If I have a fieldset with 30 fields and a legend like Advanced options, heading "advanced options foo, advanced options bar, advanced options baz" and so on seems intolerably verbose |
| 10:36 | <jgraham> | s/heading/hearing/ |
| 10:37 | <BenMillard> | jgraham, the context is helpful when you can't see the screen. :) |
| 10:37 | <BenMillard> | jgraham, you can change the configuration so it only gets read at start via verbosity controls. |
| 10:37 | <jgraham> | BenMillard: I am totally in favour of making the context *avaliable* |
| 10:37 | <BenMillard> | jgraham, the default is to read it out on every control to help novice and intermediate users understand the context of the current control. |
| 10:38 | <BenMillard> | jgraham, it's also helpful for users with short-term memory difficulties or certain learning disorders. |
| 10:38 | <zcorpan> | it appeared to me that jaws would run the legend and label together as if they were the same sentence |
| 10:38 | <jgraham> | BenMillard: It doesn't seem like novice and intermediate users would necesssarily be the ones who would need the help. But they would be the ones who wouldn't be able to switch off the verbosity |
| 10:39 | <jgraham> | Oh and hat zcorpan said :) |
| 10:39 | <jgraham> | *what |
| 10:39 | <BenMillard> | jgraham, what makes you think novices aren't helped by it? |
| 10:40 | <BenMillard> | zcorpan, the Paciello article makes that text bold so many it's a different voice, or followed by a pause. |
| 10:40 | <BenMillard> | zcorpan, if it isn't then it will still tend to make sense, assuming sensible text was used of course. :) |
| 10:41 | <gsnedders> | Ergh. rss-public are trying to put RSS into a namespace for other vocabularies to make use of it. |
| 10:41 | <jgraham> | BenMillard: Not that they're not helped, that it's not necessarily *more* helpful to them. It seems like you would only need the repition if you had difficulty retaining information about context in your head. That will of course improve a bit with practice but seems more like an innate thing |
| 10:42 | <BenMillard> | zcorpan, after changing settings it looks like Window Eyes puts an announcement between the <legend> and the susbsequent <label>. |
| 10:42 | <jgraham> | BenMillard: e.g. raeding all table headers on every cell would also be too verbose |
| 10:43 | <BenMillard> | jgraham, understanding context is the most difficult part of using a screen reader. |
| 10:45 | <jgraham> | BenMillard: But you know it's a form control and you know what the label is. How often will you also need to know what the fieldset legend is? I certianly wouldn't expect my visual browwser to keep displaying that once it has scrolled offscreen |
| 10:46 | <jgraham> | The only case I can think of where it ought to be a problem is where you have the same labels on a number of controls in different fieldsets. But that doesn't seem like the common case. |
| 10:47 | <BenMillard> | jgraham, it's a re-assuring guide. Exactly what novice and intermediate users find useful, from the tests I've seen. |
| 10:47 | <jgraham> | BenMillard: Well if you have test data you can share, that might be more convincing :) |
| 10:48 | <BenMillard> | jgraham, I don't think those tests got onto the web; we were subcontracting. |
| 10:48 | <BenMillard> | s/subcontracting/subcontracters/ |
| 10:49 | <BenMillard> | jgraham, if you have test data which shows the opposite, perhaps your POV would be more convincing? :P |
| 10:49 | <jgraham> | I still wonder if you wouldn't be better off with a "context" key that intelligently tried to give you context about your current location e.g. from table headers, fieldset, heading elements, etc. |
| 10:49 | <jgraham> | BenMillard: Of course. |
| 10:50 | <BenMillard> | jgraham, there are a variety of approaches between how verbosely ATs announce forms. IBM's HAL, for example, would only announce it at the start of the form (iirc). |
| 10:50 | <BenMillard> | (where "it" is the <legend> text) |
| 10:51 | <BenMillard> | jgraham, I think JAWS has a key like that. I guess they found users reminding themselves of the context of form controls was the common case, so they made it automatic. |
| 10:51 | <jgraham> | BenMillard: (although I do have a RNIB article that makes it sound like a problem that authors have to work around) |
| 10:51 | <BenMillard> | jgraham, software has bugs. Film at 11. :) |
| 10:53 | <BenMillard> | jgraham & othermaciej, even if you disagree with <legend> being announced on every control in one product, announcing <legend> at some point (such as when a user queries for context in the way jgraham suggests) still gives useful context. And so the use of <fieldset><legend> is A Good Thing and maybe should be done more, not less. |
| 11:14 | <othermaciej> | my objection to <fieldset> isn't based on accessibility but rather on the fact that the style of visual design that groups controls into fieldsets is no longer done |
| 11:20 | <wilhelm> | Sure, the visual design is dated, but grouping form controls with <fieldset> still makes sense. See for example http://www.bakketun.net/dev/js/tabbed-pane/ . |
| 11:26 | jgraham | is glad it has started snowing again in a way that is easy to distinguish from rain |
| 11:26 | <hendry> | wilhelm: tabs seem a little dated to me too |
| 11:29 | Philip` | is seeing more snow moving upwards than downwards |
| 11:38 | <zcorpan> | http://forums.whatwg.org/viewtopic.php?t=4043 |
| 11:39 | <hsivonen> | zcorpan: looks like we have a new attractive nuisance :-( |
| 11:41 | <zcorpan> | hsivonen: though the examples in the spec suck |
| 11:42 | <hsivonen> | zcorpan: indeed. |
| 11:42 | hsivonen | files a spec bug |
| 11:53 | <hsivonen> | does anyone have test cases for heuristic encoding detection? |
| 11:54 | <hsivonen> | even markp's Python port of chardet doesn't come with test cases, even though markp's projects usually do |
| 11:56 | <annevk> | is there a spec? :) |
| 12:01 | <jgraham> | http://diveintopython3.org/case-study-porting-chardet-to-python-3.html suggests that there should be test cases |
| 12:01 | zcorpan | looks at http://microformats.org/wiki/hcalendar#Example and wonders if it's possible to say <a href="url">summary</a> instead of <a href="url">url</a> <span>summary</span> |
| 12:03 | <zcorpan> | it seems not |
| 12:03 | <zcorpan> | that sucks |
| 12:04 | <hsivonen> | annevk: ok, I revise my question: s/test cases/demos/ |
| 12:06 | <zcorpan> | hsivonen: can't you use the input to v.nu and compare the chardet result with content-type/<meta charset>? |
| 12:07 | <hsivonen> | zcorpan: do you mean mining the v.nu logs for interesting CJK and Cyrillic pages? |
| 12:08 | <annevk> | or reverse engineer the relevant Gecko code just like Mozilla did |
| 12:08 | <annevk> | s/Mozilla/Mark/ |
| 12:08 | <hsivonen> | what I want to do is check if I've integrated the Mozilla code properly |
| 12:23 | <Lachy> | I'm trying to come up with brief, author-friendly element descriptions for the HTML 5 Reference. I've extracted all of the descriptions from the spec to start with, but now I need to revise them where necessary... |
| 12:24 | <Lachy> | can anyone suggest less technical way of describing the base element than this, from the spec: |
| 12:24 | <Lachy> | "The <code>base</code> element allows authors to specify the <span>document base URL</span> for the purposes of <span title="resolve a url">resolving relative URLs</span>, and the name of the default <span>browsing context</span> for the purposes of <span>following hyperlinks</span>." |
| 12:25 | <zcorpan> | Lachy: http://www.google.com/search?q=html+tutorial+base |
| 12:26 | <Lachy> | thanks |
| 12:26 | <jgraham> | Lachy: You probably want to say something about the fact that usually delative URLs are resolved against the document location; the base element provides a way of resolving URLs against some other location |
| 12:26 | <jgraham> | *relative |
| 12:27 | <hsivonen> | Philip`: do you have a list of pages from CJK and Cyrillic-related domains but without encoding info? |
| 12:32 | <Lachy> | "The <code>base</code> element allows authors to specify base URL that is used to resolve relative links, and the name of the default target for opening links." |
| 12:32 | <Lachy> | s/relative links/relative URLs/ |
| 12:33 | <Lachy> | (btw, these descriptions need to be really short, one or two sentences. There will be much more verbose descriptions provided as well, but this is for the summary boxes) |
| 12:33 | <beowulf> | perhaps use a word other than base to describe 'base'? root? |
| 12:34 | <beowulf> | or just 'to specify the URL that is used' |
| 12:42 | <Lachy> | beowulf, I don't understand what the problem with the word 'base' is? |
| 12:44 | <jgraham> | Lachy: The element is called "base" it sounds somewhat circular |
| 12:45 | <Lachy> | the purpose of these descriptions to succinctly describe the purpose of an element. I don't think a beginner with no prior knowledge needs to be able to fully comprehend it. Instead, these particular descriptions should serve as a useful reminder for people just using this as a reference manual |
| 12:45 | <beowulf> | Lachy: i'm probably being pedantic, but if the sentence explaining the term works withoutt using the term then it would be clearer, imo |
| 12:45 | <Lachy> | there will be other more verbose descriptions explaining things for beginners with no prior knowledge in addition to these short descriptions |
| 12:46 | <beowulf> | i am fairly safely ignored :) |
| 12:46 | <Lachy> | This uses the term "base URL" in the description http://reference.sitepoint.com/html/base |
| 12:46 | <Lachy> | the problem with removing the word base is that I can't think of a suitable, unambiguous replacement |
| 12:58 | <jgraham> | Lachy: I think you think of base as sutiable unambiguoius because you are already familiar with the concept of a base URL |
| 13:01 | <jgraham> | Just removing the word base already makes your sentence clearer |
| 13:02 | <Lachy> | jgraham, as I said, these particular descriptions don't need to be suitable for beginners with no prior knowledge. The audience for these descriptions is expected to be at least somewhat familar with the concepts already and are just using them as a quick reminder |
| 13:05 | <jgraham> | Still "The <base> element allows authors to specify a URL against which relative links are resolved [...]" is any less clear than the same sentence with the word "base" before URL |
| 13:09 | <Philip`> | "The <base> elements specifies a ..." is less verbose |
| 13:09 | <Philip`> | *element |
| 13:13 | <zcorpan> | Philip`: it doesn't need to specify a base url, it could specify a base target instead (or as well) |
| 13:13 | <Lachy> | this is what I have now: |
| 13:13 | <Lachy> | The <code>base</code> is for specifying a base URL against which relative links will be resolved, and the name of the default target for opening links and form submissions. |
| 13:14 | <Lachy> | s/is/element is/ |
| 13:15 | <Lachy> | I've left "base URL" in there because I think, once the more verbose descriptions are written that explain the concept, it will be fine. But I can always revisit the issue later if it doesn't work out |
| 13:16 | <zcorpan> | Lachy: seems good enough, along with examples |
| 13:16 | <Philip`> | hsivonen: I can give a list of URLs in certain TLDs (I guess .ru, .cn, anything else?) that didn't have an HTTP or meta charset a year ago |
| 13:29 | <Lachy> | hmm, the spec doesn't seem clear about how to handle a meta element with both name and http-equiv attributes. e.g. <meta name="description" http-equiv="Content-Type" content="..."> |
| 13:30 | <Lachy> | unless I missed something, it should specify which takes precedence |
| 13:31 | <hendry> | hsivonen: is it possible to have an attribute without a value? like 'bar' in <foo bar /> |
| 13:32 | <Lachy> | hendry, yes. There are lots of attributes that work like that in HTML5 |
| 13:32 | <hendry> | Lachy: I thought so |
| 13:33 | <Lachy> | e.g. <input disabled> |
| 13:33 | <hendry> | I want to propose changing http://dev.w3.org/2006/waf/widgets/#the-feature-element from <feature name="http://www.w3.org/geo/api/"; required="true"/> |
| 13:33 | <hendry> | to <feature name="http://www.w3.org/geo/api/"; opt /> opt for optional, default mandatory |
| 13:33 | <Lachy> | no, because that's not well formed XML |
| 13:33 | <Lachy> | the minimised attributes are only supported in HTML, not XHTML |
| 13:34 | <hendry> | Lachy: ah |
| 13:35 | <hendry> | so <feature name="http://www.w3.org/geo/api/"; optional="true" /> is a better proposal |
| 13:36 | <Lachy> | hendry, why do you want to change it from required=""? |
| 13:36 | <Lachy> | HTML5 uses <input required="required"> |
| 13:37 | <hendry> | Lachy: because the default value I think should be mandatory. it's more much more practical. In the case where widget developers leave off required="true". |
| 13:38 | <hendry> | widget developers write their code with these features in mind. if they are not there, they typically will not account for that situation. |
| 13:39 | <hendry> | i imagine in rare cases they will make their widgets work with features the might not be there. |
| 13:39 | <hendry> | hence i think mandatory will better account for the majority of typical usage |
| 13:40 | <hendry> | did that make sense |
| 13:41 | <annevk> | HTML5 uses on/off for such attributes |
| 13:41 | <annevk> | e.g. autocomplete |
| 13:41 | <annevk> | (though they still have a default) |
| 13:41 | <Lachy> | hendry, the widget spec doesn't seem to say what the default value is if its omitted |
| 13:41 | <hendry> | Lachy: i assume ommitted = optional |
| 13:41 | <Lachy> | hendry, I assumed otherwise |
| 13:42 | <Lachy> | it's not safe to make assumptions like that, the spec needs to be clearer |
| 13:43 | <hendry> | Lachy: so you assumed with required="true", it will be required? :) ok, i'll just fire off a mail |
| 13:43 | <Lachy> | oh, http://dev.w3.org/2006/waf/widgets/#boolean-attribute says the default is false |
| 13:43 | <hendry> | fs |
| 13:43 | <annevk> | zcorpan, figure { width:min-intrinsic } makes more sense to me |
| 13:43 | <hendry> | s/so you assumed with required="true"/so you assumed withOUT required="true" |
| 13:43 | <zcorpan> | annevk: does that ignore the <legend>? |
| 13:44 | <annevk> | zcorpan, display:table seems overkill although I can't quite elaborate on what the side effects might be |
| 13:44 | hendry | should read what he writes before hitting enter |
| 13:44 | <annevk> | zcorpan, it uses the minimum intrinsic width as far as I can tell, which would be that of the image |
| 13:45 | <zcorpan> | annevk: what if your figure content is not an image but a <math> element or an <ul>? |
| 13:45 | <Lachy> | hendry, I assumed that if specified a <feature name="">, then it's more likely that the feature itself would be required. But I could be wrong, since I'm not a widget developer and I don't really understand the purpose of the feature element. |
| 13:45 | <annevk> | zcorpan, http://dbaron.org/css/intrinsic/ has details |
| 13:45 | <hendry> | Lachy: the feature element is to declare upfront the need or dependency rather on a feature like Geolocation, for the widget to function. |
| 13:46 | <annevk> | zcorpan, it's called min-content there |
| 13:46 | <zcorpan> | "the intrinsic minimum width/height" |
| 13:46 | <annevk> | zcorpan, though maybe max-content is better |
| 13:47 | <Lachy> | hendry, right, so what's the point of specifying a feature element if the feature isn't needed? |
| 13:47 | <zcorpan> | annevk: that would still not ignore the <legend> |
| 13:48 | <annevk> | it does the same as display:table for your example in Firefox |
| 13:48 | <annevk> | max-content, that is |
| 13:50 | <zcorpan> | annevk: not for the second figure |
| 13:50 | <annevk> | it does for me |
| 13:50 | <zcorpan> | url? |
| 13:51 | <Lachy> | http://www.iheni.com/html-5-to-the-h1-debate-rescue/ |
| 13:51 | <annevk> | your url with "figure { display:block; margin:0 40px; width:-moz-max-content }" |
| 13:51 | <zcorpan> | right, the second figure has the legend on one line instead of wrapped at the bounds of the image |
| 13:51 | <annevk> | with "figure { display:table; margin:0 40px; }" it does not wrap at all |
| 13:52 | <annevk> | if you want wrap you should use width:-moz-min-content |
| 13:52 | <zcorpan> | you need display:table-caption on the div too |
| 13:52 | <zcorpan> | -moz-min-content doesn't play well with the <math> use case |
| 13:52 | <hendry> | Lachy: eggsactly |
| 13:52 | <annevk> | display:table-caption places it on top of the image... |
| 13:53 | <annevk> | that's annoying |
| 13:53 | <zcorpan> | annevk: did you read my email? :) |
| 13:53 | <annevk> | and also, using tables here is a hack |
| 13:53 | <zcorpan> | well i don't care which css declarations are used |
| 13:54 | <zcorpan> | my point is "I think <figure>s need a shrink-wrap width applied that ignores the <legend>." |
| 13:58 | <Lachy> | hendry, oh, so that's why you want it changed from required to optional? |
| 13:58 | <Lachy> | I mean, the attribute name |
| 14:08 | <hendry> | Lachy: yes, just posted on the public-webapps about it. now i need to get busy with other stuff. :) |
| 14:19 | <annevk> | should be pretty easy to implement howcome's stuff as JavaScript library |
| 14:19 | <annevk> | if you require a leading space |
| 14:19 | <Lachy> | annevk, do you mean the <p .foo> syntax? |
| 14:19 | <annevk> | just iterate through .attributes for something that starts with # or . and then parse that attribute appropriately |
| 14:20 | <Lachy> | sure, but I really don't think we should introduce it and make it conforming |
| 14:21 | <hsivonen> | Philip`: .cn, .ru, .jp, .kr and .tw would be very useful |
| 14:21 | <annevk> | I like it :) |
| 14:25 | <Lachy> | if people want to pursue it as a separate serialisation (i.e. not text/html) to be used for authoring, much like BBCode or Textile, and develop tools that pre-process it into normal HTML, then I'm fine with that. But there's no way we should change the text/html parser to support it |
| 14:31 | <Philip`> | It'd be even easier to implement that syntax if you require a leading space and a 'class=' |
| 14:32 | <Lachy> | there are already so many lightweight markup languages though, with many more optimisations. http://en.wikipedia.org/wiki/List_of_lightweight_markup_languages |
| 14:32 | <Lachy> | there is even one that allows you to write markup using p#foo.bar syntax (but without the angle brackets). I just can't remember what it's called |
| 14:33 | <Lachy> | I think Haml is the one I'm thinking of http://en.wikipedia.org/wiki/Haml |
| 14:34 | jgraham | tends to agree with Philip` |
| 14:37 | jgraham | is so unsurprised to find that Haml is implemented in Ruby |
| 14:37 | <jgraham> | Because it makes HTML look like Ruby... |
| 14:38 | <jgraham> | Although it's amusing that they describe it as "whitespace active" presumably because people think "whitespace sensitive == bad" |
| 14:42 | <annevk> | where at first I was willing to consider Unicode Normalization, it seems more and more like something that should not be dealt with at all on the browser level; there's just too much codepoint-equality-checking out there |
| 14:47 | <annevk> | zcorpan, btw, I believe Gecko has some selector like :first-child that does not ignore text nodes |
| 14:48 | <zcorpan> | annevk: ok |
| 14:48 | <annevk> | -moz-first-node or something |
| 14:48 | <annevk> | oh, bz just mentioned that :) |
| 14:55 | <hallvors> | is the W3C file upload validation broken? It keeps saying "Line 1, Column 0: end of document in prolog. This error may appear when the validator receives an empty document" whatever I upload. tested with Opera, Firefox and Safari... |
| 15:01 | <Philip`> | hsivonen: Like http://philip.html5.org/data/pages-with-no-explicit-charset-in-tlds-with-funny-alphabets.txt ? |
| 16:02 | <annevk> | hmm, fixing quite a few bugs in CORS |
| 16:02 | <annevk> | I wonder what those implementors have been doing while implementing... |
| 16:03 | <annevk> | I mean, it's not major holes like HTML4, but still |
| 16:20 | <karlcow> | hallvors_: you should ask to #validator if you have an inquiry about validators |
| 16:39 | <hallvors_> | karlcow: thanks, done :) |
| 16:56 | <mlpug> | if I manage to produce w3c widget (.wgt) is there some software that can render it in a meaningfull way? any browser does or do I need some special widget runner software? |
| 17:03 | <Dashiva> | Opera might, I don't know how far the current spec is from their support |
| 17:07 | <hasather> | Dashiva: pretty close |
| 18:59 | <gsnedders> | How do you get VoiceOver to actually read the page in Safari? |
| 20:48 | <jwalden> | annevk: note that it'd be |figure { width: min-content; }| now, not min-intrinsic (referenced spec got updated to correspond to -moz-*-intrinsic even if URL stayed the same) |
| 20:49 | <Hixie> | dbaron: did you say you had some non-monospace fonts available with known metrics? |
| 20:49 | <Hixie> | dbaron: or are all your fonts one character only (and thus always monospace by definition) |
| 20:50 | <dbaron> | Hixie, all my test fonts are one character only |
| 20:50 | <dbaron> | Hixie, but they're also generated by a pretty simple python script |
| 20:50 | <Hixie> | i'm trying to reverse engineer IE's <input size=""> algorithm |
| 20:50 | <Hixie> | i don't suppose i could steal your script by any chance? |
| 20:50 | <dbaron> | Hixie, I thought they used the width of a '0' |
| 20:51 | <Hixie> | if they use '0', they do something different for monospace vs non-monospace |
| 20:51 | <Hixie> | i'm trying to work out exactly what |
| 20:51 | <dbaron> | Hixie, http://hg.mozilla.org/mozilla-central/file/48e371648b83/layout/reftests/fonts/mark-generate.py |
| 20:51 | <dbaron> | Hixie, see also "raw" link |
| 20:51 | <Hixie> | sweet, thanks |
| 20:51 | <dbaron> | Hixie, there are some .svg files in the same directory |
| 20:52 | <Hixie> | neat |
| 20:52 | <dbaron> | Hixie, I have had some issues with underline offset metrics, on Mac at least... |
| 20:52 | <dbaron> | Hixie, although I'm not sure if that's related to our code adjusting underline offsets based on character extents, or something else... |
| 20:52 | <dbaron> | (the two glyphs have different bottoms) |
| 20:53 | <Hixie> | k |
| 20:53 | <Hixie> | underlining shouldn't be a concern for this particular use |
| 20:53 | <dbaron> | in our case, that actually led to different text offsets somehow |
| 20:54 | <Hixie> | odd |
| 21:42 | <ojan> | Hixie: I've already done this. |
| 21:43 | <ojan> | I have a patch I'm working on for webkit that matches IE widths |
| 21:43 | <ojan> | width = size*avgCharWidth + (maxCharWidth - avgCharWidth) |
| 21:43 | <ojan> | where avgCharWidth and maxCharWidth are taken out of the font |
| 21:52 | <jwalden> | ojan: what happens if max < avg? or are max/avg not in font metadata? |
| 21:57 | <ojan> | jwalden: how can max be less than avg? |
| 21:58 | <jwalden> | ojan: bad font |
| 21:58 | <ojan> | hm...i don't know. didn't test that. |
| 21:59 | <jwalden> | I was guessing as much, but you never know :-) |
| 21:59 | <ojan> | the real annoying thing is that mac/linux font APIs don't actually expose these values, so you have to dig into the font tables to grab them |
| 22:03 | <gsnedders> | ojan: Why on earth would you want that metadata though, except if you were copying something crazy? |
| 22:04 | <ojan> | gsnedders: sure. unfortunately, it's something crazy the web now depends upon |
| 22:04 | <gsnedders> | The web depends on lots of crazy stuff :) |
| 22:08 | zcorpan | just figured out that it was relatively easy to fix up the dom in firefox 2 with script |
| 22:10 | <zcorpan> | you just find all html5 elements and keep appending their nextSibling to self until you hit a node you expect shouldn't be a child of the html5 element (like a comment saying "end article" or a nav element or whatever) |
| 22:15 | <Hixie> | ojan: nice! thanks! |
| 22:20 | <jwalden> | speaking of html5 elements, is the plan with legend to just ignore the fact that most, maybe all, existing browsers completely mess up the figure > legend case? gecko/webkit omit the legend element (but not its contents) as often as not or magically introduce a containing fieldset, opera creates an empty legend element and spews the "contents" as siblings to it, dunno about IE |
| 22:21 | <othermaciej> | jwalden: I've proposed before that <legend> in <figure> should be renamed for that reason |
| 22:21 | jwalden | ran into this going wild with html5 markup on his personal site |
| 22:22 | <othermaciej> | <caption> would actually be a better name but makes figures break inside tables |
| 22:22 | <othermaciej> | but if we are going to consider existing browser behavior then <legend> is not good either |
| 22:23 | <jwalden> | <description> maybe? |
| 22:23 | <Hixie> | jwalden: it's not that bad, and it'll get better over time (unlike <caption>, say). The alternative is minting a new element to mean header, and we're already up to 10 or 20 depending on how loosely you define "header" -- we're just running out of good names here. |
| 22:23 | <Hixie> | <legend> will be fine in due course. it's not like we have to have it work today (unlike, say, the offline stuff) |
| 22:24 | <othermaciej> | <legend> breaks in <details> too |
| 22:24 | <othermaciej> | one new title-like name would do for both of those |
| 22:24 | <othermaciej> | and if it had sane parsing rules could be used for anything in the future |
| 22:24 | <jwalden> | existing html5 doesn't say <legend> is heading content |
| 22:24 | <othermaciej> | I think failing the Degrades Gracefully design principle is a worse problem than element proliferation |
| 22:25 | <othermaciej> | I believe I also suggested the existing <label> |
| 22:25 | <Hixie> | <label> has all kinds of preexisting baggage |
| 22:26 | <othermaciej> | I think the only worry about <label> was that existing pages might have CSS rules that assume <label> is always a form control label |
| 22:26 | <othermaciej> | so adding a <figure> would do weird things |
| 22:27 | <othermaciej> | however, if that is a problem with considering, then the problem with <legend> is worth considering as well |
| 22:27 | <Hixie> | the problems with legend are worth considering, yes. i just don't think they're as important as the problems the other elements have nor especially problematic enough on the long run to warrant a new element. |
| 22:28 | <Hixie> | if people really think it's a problem, we can comment out <figure> and <details> for now and wait for the parsers to have gotten fixed and deployed |
| 22:28 | <Hixie> | but it might take longer for the fixes to happen than if they stay in |
| 22:29 | <othermaciej> | or you could just use a new element name and <figure> could be used without waiting for browser changes to be widely deployed |
| 22:30 | <Hixie> | i have not heard any names suggested that are anywhere near as good as <legend> or <caption>. |
| 22:30 | <Hixie> | (and i've spent hours on that alone) |
| 22:31 | <othermaciej> | <rubric>, <tag>, <name> are all quasi-synonyms for label/legend/caption |
| 22:32 | <othermaciej> | (to ideally match english, a details control would have a label, and a figure would have a caption, sadly those two elements are the ones with issues) |
| 22:32 | <othermaciej> | (though I am not sure details getting form label CSS styling on its <label> would be particularly wrong) |
| 22:33 | <Hixie> | and they all suck :-) |
| 22:34 | <othermaciej> | (<legend> is actually a fruity choice of name for <fieldset> too, you wouldn't normally use <legend> in that context) |
| 22:34 | <othermaciej> | er |
| 22:34 | <Hixie> | the problem with <label> is not css, it's the forms api stuff |
| 22:34 | <othermaciej> | rather, you wouldn't use the word "legend" to describe a fieldset label, in, say, an HI guide |
| 22:34 | <Hixie> | it would e.g. prevent you from putting two form controls in a <details> legend |
| 22:34 | <Hixie> | and would bring along all kinds of DOM API baggage that isn't appropriate here |
| 22:36 | <Hixie> | other than the parsing issues, which IMHO aren't a big deal (after all, it works as well in IE as does <section>), <legend> is pretty much exactly what we need |
| 22:36 | <Hixie> | and it fits consistently with <fieldset> |
| 22:37 | <othermaciej> | <legend> is barely more semantically appropriate than <div> |
| 22:37 | <Hixie> | ? |
| 22:37 | <Hixie> | maybe this is a british english vs american english thing |
| 22:37 | <othermaciej> | as I said before, you wouldn't use the word "legend" in English normally to refer to either of the new things |
| 22:38 | <othermaciej> | (or to the label of a fieldset either) |
| 22:38 | <Hixie> | yes you would |
| 22:38 | <Hixie> | a figure has a legend |
| 22:38 | <Hixie> | a map has a legend |
| 22:38 | <Hixie> | a chart has a legend |
| 22:38 | <othermaciej> | a map has a legend, a figure has a caption |
| 22:38 | <sayrer> | legends describe symbols |
| 22:38 | <Hixie> | sure, caption would be mildly better |
| 22:39 | <othermaciej> | a legend is ordinarily a box on the side explaining symbols or colors |
| 22:39 | <othermaciej> | form controls and UI elements don't have legends, they have headings or labels |
| 22:39 | gsnedders | agrees with Hixie and sayrer |
| 22:39 | Hixie | shrugs |
| 22:39 | <sayrer> | that's curious, because I agree with othermaciej |
| 22:39 | othermaciej | though Hixie and sayrer were saying opposite things |
| 22:40 | gsnedders | just likes confusing everyone |
| 22:40 | gsnedders | also jumped into this rather late on |
| 22:41 | <othermaciej> | for that matter, a chart can have both a legend and a caption and they are two different things |
| 22:42 | gsnedders | really just agrees with a crazy mix of what everyone is saying |
| 22:43 | <othermaciej> | anyway |
| 22:43 | <othermaciej> | we are rehashing old ground |
| 22:43 | <othermaciej> | and jwalden's comment triggered my canned rant |
| 22:44 | <othermaciej> | if I continue to care enough I guess I can file it in bugzilla or the tracker |
| 22:52 | <Hixie> | ok ojan said size*avgCharWidth + (maxCharWidth - avgCharWidth) |
| 22:52 | <Hixie> | my font has two glyphs, 200 and 1000 wide respectively |
| 22:53 | <Hixie> | so the average is 600 |
| 22:53 | <Hixie> | 20 * 600 + (1000 - 600) = 12400 font units wide |
| 22:53 | <Hixie> | and the height of the font is 1000 |
| 22:53 | <ojan> | Hixie: to be clear it's whatever the font file claims to be the avg/max |
| 22:53 | <Hixie> | so 1em = 1000 |
| 22:54 | <Hixie> | so i'd expect it 12.4em wide |
| 22:54 | Hixie | checks |
| 22:55 | <Hixie> | well that didn't work. let's see what my font is really saying. |
| 22:55 | Hixie | gets the microsoft typography tool out |
| 22:59 | <Hixie> | uh, i wasn't using my font |
| 22:59 | <Hixie> | oops |
| 22:59 | Hixie | tries again |
| 23:05 | <Hixie> | ojan: well my font has 600 avg width and 1000 max width and it still doesn't give me the results i expect |
| 23:06 | <ojan> | what's it give? |
| 23:06 | <Hixie> | something's fishy here |
| 23:06 | <Hixie> | let me get back to you |
| 23:12 | <Hixie> | ooh, interesting, some padding is added to the width even if the padding style is set to 0 |
| 23:18 | <Hixie> | hmm |
| 23:18 | <Hixie> | the weird border and padding behavior complicates this |
| 23:18 | gsnedders | places a light bulb over Hixie's head and hopes all is solved |
| 23:27 | <Hixie> | ojan: i was barking up the wrong tree in quirks mode and IE was screwing up the rendering now obeying CSS rules. trying in standards mode now! |
| 23:30 | <Hixie> | ojan: yeah, you are correct, at least in standards mode. how did you reverse engineer that? brute force? |
| 23:31 | <ojan> | Hixie: trial and error |
| 23:31 | <Hixie> | nice work |
| 23:31 | <Hixie> | is it the same in quirks mode except that the width includes the padding and border? |
| 23:31 | <ojan> | and some help from dean pointing me in the right direction |
| 23:32 | <ojan> | Hixie: not sure off the top of my head, but that sounds right |
| 23:34 | <Hixie> | outer width is 2px bigger in quirks mode, it seems |
| 23:34 | <Hixie> | which seems backwards |