Re: [whatwg] Zip archives as first-class citizens
On 28 August 2013 14:32, Anne van Kesteren ann...@annevk.nl wrote: We have thought of three approaches for zip URL design thus far: * Using a sub-scheme (zip) with a zip-path (after !): zip:http://www.example.org/zip!image.gif * Introducing a zip-path (after %!): http://www.example.org/zip%!image.gif * Using media fragments: http://www.example.org/zip#path=image.gif Am I missing something? I assume you want to basically send a whole bunch of files down the pipe when any one of them is requested, not send the individual file's bytestream from a zip. If so, then why is this not acceptable: === a href=http://website.example/game.webzip/load.html;Load Game/a GET http://website.example/game.webzip/load.html Accept: application/webzip, */*;q=0.1 # UA supports looking inside zips 200 OK Content-Type: application/webzip Content-Location: /game.webzip # server knows to send zip -- vs. -- a href=http://website.example/game.webzip/load.html;Load Game/a GET http://website.example/game.webzip/load.html Accept: text/html, */*;q=0.1 # no support 200 OK Content-Type: text/html Content-Location: /game.webzip_files/load.html # server knows file resides elsewhere === HTTP server knows to send a zip file if UA supports a new content type. HTTP server also knows to send back the file from inside the zip (or an unzipped sibling directory to contain the file to serve) to clients that do not support the new mime type. This can be as simple as a mod_rewrite rule executed iff mod_webzip is not loaded. MIME type would only be requested in Accept header by supporting client if the path contained /\.webzip\// otherwise omitted. All relative URIs work as if the file was at the request URI. No multiple scheme hassles, no multiple fragment hassles. No special delimiters that might already be in use. The change in filename also means a concious action on part of the webmaster to allow access. As suggested, the file format can be a stricter form of zip that doesn't allow multiple file tables. The server would have to validate this before sending the file As suggested, the content types of resources in the zip would be determined from a list of file extensions defined by the spec. Anything else get's a default such as application/unknown. -- Nicholas.
Re: [whatwg] Default scope for table headers
Merci beaucoup Pierre. That was quite a detailed reply! -- Nicholas.
[whatwg] Default scope for table headers
http://www.w3.org/TR/html-markup/th.html#th.attrs.scope Says nothing about what a UA should do by default, nor when scope can be omitted due to such defaults. I suggest explicitly defining defaults for the benefit of both UAs and HTML authors. I would expect the defaults to be defined something like this: Rule 1) If a row begins with zero or more empty TD elements, followed by one or more TH elements and no further TD elements, and all previous rows in the table also satisfied this Rule, the default scope is col for each TH in the row. Rule 2) If a row contains one or more TH elements, followed by one or more TD elements and no further TH elements, the default scope is row for each TH in the row. Rule 3) If a table contains two or more columns, and a row in an implicit or explicit TBODY row group contains a single TH element which spans all columns, and any previous rows in the row group also satisfied this Rule, the default scope is rowgroup for that TH element. Rule 4) If an implicit or explicit TBODY row group contains two or more rows, and the first row of the group contains a TH element which spans all rows in the group, and any previous cells in the row also satisfied this Rule, the default scope is rowgroup for that TH element. Rule 5) If a TH cell which satisfied Rule 1 spans two or more columns, and those columns constitute a complete COLGROUP, the default scope is colgroup for that TH element. This describes the most complex form of an 'obvious' table I can think of at this time in the morning, where obvious means there can be no other expected behaviour: colcolcolgroupcolcolcolcolgroupcolcolcol thead trtdtdth colspan=3Section1th colspan=3Section2 trtdtdthCol1thCol2thCol3thCol1thCol2thCol3 tbody trth rowspan=3CategoryAthRow1td...td...td...td...td...td... trthRow2td...td...td...td...td...td... trthRow3td...td...td...td...td...td... tbody trth rowspan=3CategoryBthRow1td...td...td...td...td...td... trthRow2td...td...td...td...td...td... trthRow3td...td...td...td...td...td... tbody th colspan=2Totaltd...td...td...td...td...td... Resulting in the following: The cells containing Section1 and Section2 has default scope colgroup The cells containing Col1, Col2 and Col3 have default scope col The cells containing CategoryA and CategoryB have default scope rowgroup The cells containing Row1, Row2, Row3 and Total have default scope row Without the COLGROUP elements, the cells containing Section1 and Section2 would have default scope of col instead. Without the THEAD and TBODY elements, the cells containing CategoryA and CategoryB would have default scope of row instead. For any TH element, an explicitly present scope attribute overrides the default (duh). Since this is mark-up based, the rules apply equally to rtl tables (column order is displayed differently, but mark-up is the same). Also, personally, I would use empty TH elements in the top left, but the algorithm should cover either case. An empty TH element would still satisfy the 'one-or-more TH elements' condition, so doesn't need to be mentioned in the rule. When determining 'empty' in the first rule, an anonymous text node containing only collapsed white space and/or non-breaking space characters, should be ignored. Some HTML authors and authoring programmes put nbsp; in cells to prevent them from collapsing. Rules 3 and 4 cannot apply to a single TBODY at the same time. The example table uses Rule 4. Characteristics which prevent any defaults from existing in the table: a) A row of TH elements after some rows of TDs in the same (implicit or explicit) TBODY. b) A TBODY element containing a row of two or more TH elements, if a THEAD or TFOOT exist for this table. c) The table contains no TD elements. d) maybe more? It would not be clear in either (a) or (b) whether the TH[scope=col] elements from earlier rows apply to the rows under the second set of headers, so all defaults should be removed, and let the author tell us what s/he's trying to do. For (c) there's no point in having defaults anyway :-) This means that (use_scope_defaults == true) can only be determined at the end of parsing the table. I hope that this is not a deal-breaker, or that someone else can propose a better algorithm which does not depend on unparsed parts of the table yet still does The Right Thing. -- Nicholas.
Re: [whatwg] Default scope for table headers
On 1 October 2012 10:21, Michael[tm] Smith m...@w3.org wrote: Don't look to that document for any information about default UA behavior, or anything at all about UA processing behavior. I tried to make that very clear in the abstract and intro for that document. Sorry, I never saw that: https://encrypted.google.com/search?q=html5+default+header+scope for me, returned: Coding An HTML 5 Layout From Scratch | Smashing Coding coding.smashingmagazine.com/.../designing-a-html-5-layout-from-sc... HTML th scope Attribute www.w3schools.com/tags/att_th_scope.asp - this domain is on my block list, yet still shows up?! th – table header cell - HTML5 www.w3.org/TR/html-markup/th.html - so I clicked here :-) td – table cell - HTML5 www.w3.org/TR/html-markup/td.html I think what you want is already define[d] in the actual HTML spec: So it is. Bad Google, no Cookie headers for you. http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#attr-th-scope http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#internal-algorithm-for-scanning-and-assigning-header-cells But if that's missing something you should file an HTML spec bug. I got here by reading through old posts at 456bereastreet and found this one: http://www.456bereastreet.com/archive/200910/use_the_th_element_to_specify_row_and_column_headers_in_data_tables/ It struck me that the scope attributes should have default values for such a simple table. Having read the algorithm you linked to, and realising I had already read it several moons/aeons ago, I see they do different things but towards a similar end goal. The HTML5 algorithm defines how a UA associates headers with a particular data cell, e.g. for speaking aloud. My algorithm changes the default value the scope attribute (from which the cell headers can then be computed, via the existing algorithm). I believe applying the HTML5-specced algorithm to the table I used as an illustration would result in the same headers being used for each cell as if my own algorithm was used (though I have not done a thorough verification), leaving just these questions: Are there use cases where the value of the scope attribute matters other than as an intermediary for computing the headers applicable to each cell? If not, are there use cases where either the data cell headers have not yet been computed or they are unavailable (perhaps while Javascript DOM tree walking?) where access to the scope attribute would be helpful? If either of these can be answered in the affirmative, then I believe a bug could be raised. Anyone care to chime in? -- Nicholas.
Re: [whatwg] image element
On 30 Jul 2008, at 4:49 am, Ian Hickson wrote: On Tue, 20 Mar 2007, Nicholas Shanks wrote: I asked for the resurrection of HTML+'s imagefallback/image element last month. The reasons I cited were exactly the same as the reasons being given now in favour of the video element, however I was told (paraphrasing) Why bother, you can just use object and That would break existing implementations (though no such implementations were cited). To continue this: The video and audio elements are being introduced because they have DOM APIs that exceed that of object, and we don't want to overload the general element with features specific to certain kinds of media. By analogy, images could have specific APIs too (dontScale/scaleToFit/ stretchToFit, nextFrame/previousFrame/startAnimating/stopAnimating). These aren't being proposed at present, but overloading object is not something it seems like we should be telling people to do. I would expect, if an analysis was done, that the number of people using image/ as an empty element (thinking they were using img), and the number of people using image/image as was defined in HTML+ are both no higher than the background noise of misspelled tags. As such, I don't believe it would be to any vendor's detriment to change the meaning of an opening image tag to not be empty, since the numbers of pages rendered incorrectly would stay about the same (just that it would be a different set of pages). The action, however, would free up the tag for future use. So again, I ask for an image element to replace img. Benefits include: - As video would cater for video/* MIME types, image would cater for image/* I don't see how this is a benefit over img. In order of importance to me: 1. It's spelt correctly. 2. It's not an empty element. 3. It's spelt correctly. - The alt and longdesc attributes can be part of the fallback content, allowing markup. If you need markup in the fallback, use object. (Or, better, consider exposing the content to everyone and not making it only available to those who don't see the image.) The point of fallback is ‘help for people who can't see the image’ rather than ‘an explanation of the image suitable for all’. Of course, if you can provide the latter, that's great, and there's no problem. Fallback content could be as simple as Figure 2, where the surrounding text discusses the image sufficiently that it isn't necessary to see the image, but users still want to know which image element on the page that text was referring to (so they can download it to disk, or whatever). - You don't have to provide a type attribute and match on: object [type^=image/] Seems like img handles this too. Aye, but img gets me very angry. I believe this was the worst moment in the history of HTML: http://1997.webhistory.org/www.lists/www-talk.1993q1/0182.html Why did nobody stop this guy at the time? We're still cleaning up his mess 15 years later :-( — Nicholas Shanks. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] embed feedback
On 24 Jul 2008, at 10:12 am, Ian Hickson wrote: On Sat, 19 Aug 2006, Shadow2531 wrote: If text/plain is sent, I expect it to fail unless you have a text/ plain plug-in installed. Even then though, the video wouldn't play because it'd be a text/plain plug-in, not a video plug-in.. However, if no type at all is sent ( like if you're loading a local page that embeds a local wmv file), then I'd say use the extension as a backup. There are a lot of videos sent as text/plain. I'm not sure we can ever get around that. I would really like a browser with preference I can activate that turns off all kinds of sniffing and hacks that the browser does to support the ‘real internet’ (so, in this case, it would display text). This would be incredibly useful as a debugging tool when working on large web sites that I didn't author. — Nicholas Shanks. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] Removing @rev
On 14 May 2008, at 12:11 AM, Ian Hickson wrote: On Tue, 13 May 2008, Křištof Želechovski wrote: Removing @rev is harmful for Lynx because that is how it decides who the author is. Removing rev= from the spec doesn't preclude Lynx still supporting it for legacy documents, and for new documents, rel=author is preferred and is trivially supportable given support for rev=made, so I don't think this is a particularly convincing argument. For what it's worth, I always press 'c' before going hunting for a contact address. It usually doesn't work, but that's life I guess. Ian: would it be too much to have the spec say that @rev is valid if and only if its value is made or owner? That way I can continue supporting older versions of lynx until people have updated to a version supporting rel=author I generally prefer lynx over links, w3m and such when I'm ssh'd into another machine, so I don't know much about them, but if they also support @rev then that would be more reason to keep it in with these fixed values. — Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] Feeedback on dfn, abbr, and other elements related to cross-references
2008/4/23 Ian Hickson [EMAIL PROTECTED]:
Summary: I've made the title= attribute on abbr optional again.
Maybe we need a smart validator that maintains a set of abbreviations
it comes across, if an abbr with no title attribute is encountered
that isn't in the set of already seen abbreviations, a message is
displayed to the web developer saying the new abbreviation should have
a title.
This would apply to acronym plurals with -s too because UAs might use
similar string hash matching heuristics to expand repetitions of
acronyms.
Once we get outside English's simple case system this will begin to
break down however, as genitive and demonstrative and other cases will
produce different element content.
On Mon, 21 Apr 2008, Smylers wrote:
Why should HTML 5 bother to solve the very narrow case of disambiguating
words from abbreviations, but not solve it more generally to include the
other cases?
Indeed.
This is a good point. Smylers, do you think we should remove abbr
altogether and leave solutions to ambiguity problems to something
other than HTML?
On Mon, 21 Apr 2008, Patrick H. Lauke wrote:
Assistive technology is certainly a valid use case here.
Why? It doesn't seem to be the case to me that people using ATs are any
less able to work out what an abbreviation is than anyone else.
I think the point is that written and spoken language are not the same.
If I see etc. written down, I read it as et cetera in my mind's
voice, sometimes even as blah blah blah!
This usage has nothing to do with disambiguation, and is only
concerned with text-to-speech (even if that speech is unspoken). As
such, these kinds of abbreviations should not be marked up IMO, but
left to the synthesizer's lexicon.
On Mon, 21 Apr 2008, Nicholas Shanks wrote:
We need to go through this more methodically before making a decision. I
hope the following aids matters.
More methodically than
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-April/014470.html
...? I'm not sure exactly what you have in mind! :-)
What I meant was you were just addressing people's points as they came
up. If we want to do this properly we need to ensure we have covered
every aspect from the beginning.
Set up a focus group or something :)
Situations where expansions of abbreviations are needed:
It should not
be required that the user screw around looking for the acronym with a
dotted underline.
Abbreviations are no more special here than any term of art.
except that HTML in is past incarnations provided a solution. The
difference has already been created. we just have to decide where to
go from here. Maybe we could remove it?! That way abbreviations and
other jargon are on a level field again. I'm not suggesting new
jargon element though.
I didn't expect any autoexpading at all. Ever, even with abbr present
with a title= attribute. Why would one want that?
Well you should expect it. Lots of people *may* want that from time to
time (me included, and I do not require ATs). It depends on the
document i'm reading.
That would be really annoying.
To you perhaps, when you already know what's being referred to. I'll
betcha there's been times when you wished someone would stop writing
in an overly shorthand form.
We have acronyms and abbreviations for a reason -- to make
things shorter! :-)
Not so. In our case it may be to make the written word shorter.
Sometimes it's for marketing reasons, to make things more memorable,
or humorous. And shorter isn't always better, especially in spoken
content.
For the record I pronounce i.e. as individual letters. I realise it
stands for /id est/, but I would never consider it as an abbreviation
for some English term like 'that means' or 'that is to say'.
It's quite obvious that the BAR in RAISE THE BAR is not an acronym.
Only if you know English. ('you' being the User Agent who has to
decide how to expand/pronounce it). It is not reasonable to expect
UAs, other than perhaps TTS engines, to correctly identify this. And
to the person who suggested it be written in lowercase, I explicitly
said it was a newspaper headline. You should not change the case of
printed material when transferring it to electronic form,
reproductions should be faithful to the original, and use uppercase
characters rather than style transformations (since they might not get
applied).
Erroneous expansion of non-abbreviations that match a previously defined
abbreviation is I think the hardest thing to avoid.
Why would the user request expansion of non-acronyms?
The user would say Hmm, not following this essay very easily. Dear
web browser, please expand all acronyms for me.
The UA would then have to decide what is or is not an acronym, if they
are not marked up, this makes the job more error prone and results in
a poorer user experience.
Why does probibiting abbr.../abbr without title= prevent UAs from
searching previous abbr elements?
In this instance
Re: [whatwg] Feeedback on dfn, abbr, and other elements related to cross-references
Ian, I think you have made a mistake. We need to go through this more methodically before making a decision. I hope the following aids matters. First, lets think about who will use abbreviations and why they need them, second, think about where the information could come from. Situations where expansions of abbreviations are needed: 1) People unfamiliar with the topic being discussed. This can happen if you click a link to an anchor half-way down a page and miss the introduction, or you are reading about a topic new to you. It should not be required that the user screw around looking for the acronym with a dotted underline. This would be terrible for users of non- visual UAs or UAs that don't differentiate abbrs from normal text. 2) Documents that exist as both a single page, and as multiple pages (like large web specifications). Should the expansion occur once per file? That would require additionally marking up every abbr at it's first occurrence on a page when splitting the single-page version. 3) Documents that use the same acronym to mean different things in different contexts/sections. For example, take that both abbr title=United States of AmericaUSA/abbr and abbr title=United Space AllianceUSA/abbr previously occurred in the document, and you *don't* want, as an author, for every future use of either term to be expanded by default (so will not provide titles for all occurrences). I then jump into the middle of a page from somewhere else and see The USA's fleet of Space Shuttles are refurbished by USA, LLC. and wonder what's going on! There's no way to tell which is which without heuristical analysis of the language, so the UA can't auto-expand based on a single previous occurrence, which I think is the behaviour you were expecting by disallowing abbrs without titles and removing the referencing. 4) Documents where the acronym and an identically spelled word appear. For example your current system would *require ambiguity* in the admittedly somewhat unlikely newspaper headline: h1abbr title=British American RacingBAR/abbr RAISE THE BAR IN FORMULA ONEh1 Is the second BAR an acronym, which is prohibited from being marked up, or not?No way to tell without heuristical analysis of the language. Certainly not something most UAs will be doing, even for English. What hope would Nahuatl have? At least with abbrBAR/abbr you can tell that it *is* an abbreviation, and can go look for the reference. Telling when a word that's not marked up is or isn't an acronym (so deciding if the UA should provide an expansion) is much harder. Ideally users need to have on-demand expansion of any abbreviation they come across, in any situation, regardless of how competent the HTML author was. Erroneous expansion of non-abbreviations that match a previously defined abbreviation is I think the hardest thing to avoid. Where should these expansions come from? The following fallback list seems reasonable: 1) Inline with @title, the way it's currently done. 2) By referencing, either automatically by the UA or explicitly marked up, an expanded occurrence of the acronym. 3) Glossary file in link tag, which the UA can apply if unambiguous or could be referenced by markup. Not currently a feature of any UA. 4) User's application- or system-wide lexicon file, containing terms in that user's field of occupation. On the Mac OS this is located under VoiceOver Utility→Speech→Pronunciation. 5) Lexicon of the synthesiser, if one is being used. You are prohibiting (2) from being used, with the following consequences: a) Documents will either mark up every acronym with an abbr title=… tag—user agents that expand these by default (primarily aural as I understand it) will appear very verbose—or, b) Documents will only mark up the first occurrence. UAs that do not process subsequent occurrences of the abbreviation (currently all of them), will suffer from lack of definitions. c) In documents with the same abbreviation occurring for two different expansions, UAs will have no means of disambiguating without linguistic processing. Using a to achieve referencing is a very bad idea, as it will pepper documents with little blue underlined words and will and up far more distracting than useful to users. Designers will also hate it, so it will end up not being used at all. Lastly, by disallowing the title attribute to be omitted you make things unnecessarily difficult for currently valid HTML4 to migrate to valid HTML5. — Nicholas Shanks. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] Hyperlinks with |title| attribute
On 5 Apr 2008, at 11:57 pm, Ian Hickson wrote: On Sat, 5 Apr 2008, Christoph Päper wrote: Should (or may) user agents display the content of the |title| attribute of an |a| element in the GUI window caption (if the window manager used supports such), when the user followed the link and the retrieved resource is in a format that does not support specifying a title by itself (e.g. many image formats)? What about resources that could have a title but do not (e.g. a non-conformant HTML document without |title| element)? The alternatives are to display nothing or the name of the resource (file name), the final part of the path. I do not believe this is in scope for the specification. I don't see an interoperability issue here. But it does sound like a potential security issue, re-titling external documents. — Nicholas Shanks. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] ins, del, and mark crossing element boundaries
On 2 Apr 2008, at 12:43 pm, Daniel Glazman wrote: Matthew Paul Thomas wrote: I don't know what use this observation is. Maybe it means ins, del, and mark shouldn't be HTML elements, but should be something else instead. Excellent post. I concur. Excellent summary of how these elements are not hierarchical, but overlaid over the content of the document. The only way I can see to have these in a well-formed DOM is by using empty elements for both the start and end. p…ins-start/…/pp…ins-end/…/p However, that said, I believe more strongly that the ins, del and mark are metadata about the document, not specifically *part* of the document, and as such, perhaps they need to be moved completely out of flow, either into the head or into an auxiliary metadata file. They are seldom used AFAICT, not being mentioned on [1], and I think there is a valid reason for this lack of use which should be addressed. Are the elements necessary in HTML, should the information they convey be specified in another manner completely? [1] http://code.google.com/webstats/ — Nicholas Shanks. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] Video
On 2 Apr 2008, at 4:53 pm, Krzysztof Żelechowski wrote: Dnia 01-04-2008, Wt o godzinie 23:38 +0100, David Gerard pisze: The actual solution is a large amount of compelling content in Theora or similar. Wikimedia is working on this, though we're presently hampered by a severe lack of money for infrastructure and are unlikely to have enough in time for FF3/Webkit/HTML5. I tried converting Flash to Ogg and the resulting file was five times larger. Chris Err, yeah. Don't do that :-) Transcoding from one lossy format to another is a sure way to increase file size and decrease quality. Re-encode it into ogg from the source material, and make sure your ogg exporter settings are apropriate for the delivery medium you want. — Nicholas Shanks. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] [HTML5] Accessibility question
On 1 Apr 2008, at 9:00 am, Benjamin Hawkes-Lewis wrote: Hmm … http://www.w3.org/TR/wai-aria/#hidden seems to be specified as equivalent to visibility: hidden, a property that theoretically shouldn't affect speech rendering but does (accidentally) hide content from screen readers. It doesn't say anything about display: none;. I know that everyone already knows this, but I think a reminder might be timely: Be careful not to confuse screen readers, who's job it is to read what is displayed on the screen, with a voice browser, who's job it is to parse a HTML document into a DOM tree and apply media-less and aural CSS (and potentially never display anything on screen). visibility: hidden and display: none should both hide content from screen readers. — Nicholas Shanks. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] [HTML5] Accessibility question
On 1 Apr 2008, at 10:14 am, Benjamin Hawkes-Lewis wrote: Nicholas Shanks wrote: I know that everyone already knows this, but I think a reminder might be timely: Be careful not to confuse screen readers, who's job it is to read what is displayed on the screen, That's something of a simplification; the word read in particular is as likely to confuse as to clarify (yes, the name doesn't help here). It's the job of a screen reader to provide people with severe visual impairments with access to a computer system. Well i would disagree: that's the job of an accessibility suite for the blind. A screen reader is just one component of such a suite. That regularly entails more than reading what is displayed on screen, including also things like querying document or application models and constructing further internal models on top of those (for example, to produce a list of links, or extract hidden help text, or construct a text-stream view of a webpage in a virtual buffer). http://www.rnib.org.uk/xpedio/groups/public/documents/PublicWebsite/public_withoutvisinfosheet.hcsp http://en.wikipedia.org/wiki/Screen_reader A program whose 'job it is to read what is displayed on the screen' works better as a description of simpler text-to-speech programs (which also exist). Am at work and haven't time to read these at the moment. Will do so this evening. with a voice browser, who's job it is to parse a HTML document into a DOM tree and apply media-less and aural CSS (and potentially never display anything on screen). I agree it's important to distinguish screen readers from voice browsers. Two example differences from an end-user perspective: 1. Screen readers typically provide access to an entire system rather than simply being a self-voicing application for browsing the web or an application that happens to include speech output. 2. Screen readers also typically output braille. :) Then I would call such software a screen reader + braille renderer + hacks around in your OS program doing nasty things program. I don't think a pure screen reader should know anything about CSS or DOM or an application's internals. visibility: hidden and display: none should both hide content from screen readers. I don't think it's that clear-cut in theory or practice. Screen readers don't map directly to the speech/aural or braille media types. But they don't map directly to the screen media type either. They involve different modes of access, not just a different media type. See also one slice of the complicated story at: Does JAWS support cascading style sheets (CSS)? http://www.freedomscientific.com/fs_support/BulletinView.cfm?QC=1165 Besides my opinion that JAWS is probably the worst example of an accessibility program that exists, it is far from being just a screen reader. — Nicholas Shanks. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] [HTML5] Accessibility question - SSML
Well I already do include embedded SSML on my website. I also submitted some XSLT to transform XHTML into a full SSML document which can be piped to speech synthesisers like Swift, that understand the format. http://bugs.webkit.org/show_bug.cgi?id=10363 On 18 Mar 2008, at 10:23 pm, Keryx Web wrote: Benjamin Hawkes-Lewis skrev: I think it's a mistake to assume a accessible or screen-reader- friendly view should be non-interactive. In so far as this is true at all, it's largely a result of web interactivity depending on non-standard widgets. AFAICT, this is one of the problems HTML5 tries to solve. Hear, hear! We also need to work with screen readers and browser developers so that that CSS media rules actually start to be applied. And Webkit should join the ARIA party! A thought (an just a thought), however, that might be worth investigating is if SSML could be embedded into HTML, using similar principles as is being considered for SVG. Lars Gunther — Nicholas Shanks. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] [HTML5] Accessibility question
Paul is right, you can just use:
@media (screen, print, handheld) { .foo { display: none; } }
Since no screenreader i know of supports aural media you can't yet do
it the other way around (default to none and show for aural)
On 17 Mar 2008, at 2:08 am, Nicholas C. Zakas wrote:
I know the topic has come up a few times, but I'm still wondering if
HTML 5 should provide some sort of logic around content that should
not be displayed by browsers but should be read by screen readers.
Perhaps a noview boolean attribute on each element could be used
to tell UAs not to render the content but to report it to screen
readers? Or maybe a noview/ element could be used to surround
content that shouldn't be displayed but should be accessible to
screen readers?
Any thoughts?
-Nicholas
Looking for last minute shopping deals? Find them fast with Yahoo!
Search.
— Nicholas Shanks.
smime.p7s
Description: S/MIME cryptographic signature
Re: [whatwg] Reverse ordered lists
On 9 Jan 2008, at 16:54, Simon Pieters wrote: Siemova wrote: The easiest, most obvious solution would be to create an attribute for Ordered Lists -- let's call it order= -- which would have two possible values: ftl (first to last) and ltf (last to first). if we go this route, i'd prefer ascending and descending as the two. I would assume they're also easier to understand for non-english speakers A boolean reverse= attribute or so would also work, I guess. i wouldn't mind either way. I think the idea is great though. those people having trouble should have said something earlier! - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] The issue of interoperability of the video element
On 27 Jun 2007, at 09:28, Maik Merten wrote: Browsers don't rely on the OS to decode JPEG or PNG or GIF either In my experience that seems to be exactly what they do do—rely on the OS to provide image decoding (as with other AV media). I say this because changes that had occurred in the OS (such as adding JPEG-2000 support) are immediately picked up by my browsers. Firefox can decode WMV while it can't on some other (and in this case content providers may choose to not provide content in alternative formats because Internet Explorer and Firefox on Windows cover 95% of potential customers and they all can do WMV - that could grow to an unfortunate situation where actually improving interoperability with one media system slams the door for Linux and MacOS users). WMV 9 is supported on the Mac OS via a (legal) download, so only Linux would get screwed. Once the download is installed, every app that uses QuickTime (including apps that have their own codecs too, such as RealPlayer, VLC) immediately gain the ability to play WMV files. Same is true for the Theora codecs from xiph.org. I assert that any codec written by a browser vendor and available only within that browser is user-hostile (due to lack of system ubiquity), likely to be slower and buggier than the free decoding component written by the codec vendor themselves, and detracts from the time available for implementing other browser changes. - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] The issue of interoperability of the video element
On 27 Jun 2007, at 11:55, Robert O'Callahan wrote: In my experience... You do not know what you are talking about. Firefox does not use OS image decoders. And I don't use Firefox, so my point is still valid. Please don't inform me of what you think I know or do not know, it is impolite. For your future reference, Robert, the browsers I am familiar with and was referring to in my statement about image decoders are WebKit- based browsers, OmniWeb 4.5 (historically), Camino and iCab 3. I avoid FireFox and Opera due to their non-native interfaces and form controls. Given your statement I may be incorrect about Camino though. We use official Ogg Theora libraries. No-one's suggesting reimplementing codecs. We're talking about integrating existing codecs into the browser, and shipping them with the browser. This is only possible if the codec is free. I thought we were talking about the problem of adding non-free codecs (namely WMV and MPEG4) to free software, (possibly also involving reverse-engineering the codec). - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] The issue of interoperability of the video element
I don't quite get some of the arguments in the thread. Browsers don't (and shouldn't) include their own av decoders anyway. Codec support is an operating system issue, and any browser installed on my computer supports exactly the same set of codecs, which are the ones made available via the OS (QuickTime APIs in my case, Windows Media APIs on Bill's platform, and from the sounds of it, libavcodec on the Penguin) So Mozilla and Opera wouldn't need to license MPEG to get MPEG support, they would either get it if the user had an MPEG codec installed, or they wouldn't. And that would be no different from IE or the user's other browsers, so they wouldn't be at a disadvantage. If a browser implemented it's own codecs, they would almost certainly be slower and more buggy than the ones that exist on the system already. WRT Apple and Ogg Theora: Iagree that given the high risk-to-reward cost of Theora to Apple, it's their right not to ship it, but it would be most consumer unfriendly not to link to xiph.org when a theora video is first encountered. And this link should probably be a redirect via the apple.com domain so that they can intercept and change the path if the destination changes. Hard-coding URLs for codecs into either the HTML or the shipping software is a bad idea. - Nicholas. smime.p7s Description: S/MIME cryptographic signature
[whatwg] One document or two?
Various people have expressed opinions in favour of either one spec to rule them all, or two specs for different audiences. Is not the simplest solution to have two views upon the same spec? HTML 5, Full Version (User Agent Edition) foo is deprecated and should not be used, but you have to support it anyway. HTML 5, Abridged Version (Web Author Edition) foo is deprecated and should not be used. You can even have them at the same URL, with a pair of radio buttons to toggle between them (which just toggles display: none on a class to hide the unnecessary info: lt;foo is deprecated and should not be usedspan class=full, but you have to support it anyway/span.) Since I anticipate 99% or more of people who will read the document will be HTML authors finding out about the new spec, Abridged should probably be the default view. - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] return lowercase hex values for fillStyle and strokeStyle
On 10 May 2007, at 07:31, Ian Hickson wrote: On Tue, 29 Aug 2006, Anne van Kesteren wrote: Instead of returning an uppercase six digit hex value I suggest returning a lowercase value for compatibility with what UAs (including IE) currently do for CSS already and what Mozilla already does for canvas. Done. On Tue, 5 Sep 2006, Christoph Päper wrote: It may be the right decision on compatibility grounds, but other than that lowercase hexadecimal digits (0-9, a-f) are almost always a bad choice, because a, c and e have no ascenders like every hindu-arabic decimal digit has and thus make the number harder to read. This obviously does not apply to fonts with old-style numerals aka. text figures, where 0, 1 and 2 have neither ascenders (like 6 and 8) nor descenders (like 3, 4, 5, 7 and 9), but those are rather unlikely to be used in a programming environment. You can use uppercase letters when setting, which is where you're most likely to see this. It only affects the getter. I think consistency with the rest of the platform will get us at least as much of a win for authors as would be gotten from uppercase letters. Would it not make more sense to fix the UAs. lower-case hex is horrible to read. - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] return lowercase hex values for fillStyle and strokeStyle
On 10 May 2007, at 08:45, Anne van Kesteren wrote: On Thu, 10 May 2007 09:02:52 +0200, Nicholas Shanks [EMAIL PROTECTED] wrote: Would it not make more sense to fix the UAs. lower-case hex is horrible to read. Feel free to convince the Microsoft Internet Explorer team. Then again, it's not like you'd actually read the return value of .fillStyle and .strokeStyle yourself anyway... I assume one would use these getters primarily when debugging a website during its development, and as such they would be read by human eyes, and readability is quite important in the case of debugging. It is easy to scan over DECA67 but deca67 might appear more like a variable name, distracting the developer, if only momentarily. - Nicholas. smime.p7s Description: S/MIME cryptographic signature
[whatwg] HTTP's Referer and Set-Cookie2 headers
May I suggest that you also allow the DOM referrer attribute to match a HTTP Referrer header if one is present, and fall back to the Referer header otherwise. This provides for HTML 5 compliant UAs to be forwards compatible with a potential future HTTP spec that fixes the typo. Also, the DOM cookie attribute discussion should mention the HTTP Set- Cookie2 header. Don't know what it should say though. http://www.whatwg.org/specs/web-apps/current-work/#resource - Nicholas. smime.p7s Description: S/MIME cryptographic signature
[whatwg] Semantic use of the font element
I have a website which discusses typography, web design, and computer fonts. It recently occurred to me that my use of spans with style elements was not really the most semantic method of getting across my meaning, and I would be better using the font element. My content goes something like this: span style=font-family:HelveticaThis is a sample of Helvetica/ spanbr span style=font-family:ArialThis is a sample of Arial/span Which loses its visual meaning if the CSS is stripped, overridden, or not understood, and further more I cannot supply fallback fonts (since that would create a misleading visual appearance) and so here contradict the CSS guidelines for the font-family property. Would it not be more correct to use: font face=HelveticaThis is a sample of Helvetica/fontbr font face=ArialThis is a sample of Arial/font In this instance I am saying to the browser that the font is the critical part of that run of text, and the fact that font doesn't support fall-back works in my favour here, as well as the usage being fully compatible with graphical UAs. - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] Parsing: comment tokenization
On 7 Apr 2007, at 02:56, Anne van Kesteren wrote: The tokenization section should also handle: !-- !--- as correct comments for compat with the web. This means that ! shows -- and that !- shows --. Why on earth is this a good idea? AFAIK browsers and other HTML clients don't currently treat these as comments, and compelling them to do so will cause several problems: 1) Web developers currently expect things like !--5?-- to result in the comment greater than five?. Changing such expectations on a whim is harmful. 2) A double HYPHEN-MINUS delimits comments within tags, this provides compatibility with XML and SGML and changing this needlessly in HTML5 will just complicate conversion. 3) You claim compat with the web but don't provide any evidence to support that. Are there huge numbers of sites expecting !-- to represent a comment without content? Can such sites not be fixed instead of polluting HTML with additional rules? I'd rather have a handful of broken sites that their authors will fix than saying to the other 99% of authors hey, you can now do this and ending up with millions of broken sites. (I say broken, because they will not be backwards compatible with current or previous UAs) - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] Parsing: comment tokenization
On 7 Apr 2007, at 15:47, Anne van Kesteren wrote: On Sat, 07 Apr 2007 14:27:14 +0200, Nicholas Shanks [EMAIL PROTECTED] wrote: AFAIK browsers and other HTML clients don't currently treat these as comments, [...] Well, sorry to say, you got your facts wrong. *sigh* I guess that means we're already down the hole. Can we at least stop digging? Even you must (begrudgingly?) admit that comments formatted as in your original post are not backwards compatible, even if they do reflect the state of modern UAs as you say. In light of this, I suggest instead acknowledging that UA developers will need to support it in quirks mode, but instruct authors not to use this syntax. Some dire warning about future revocation and ice caps melting might help us here. Of course, the quickest way to get authors to do that would be to fix this bug in WinIE, but I don't think Microsoft higher-ups would allow that. :-/ On 7 Apr 2007, at 14:00, Kornel Lesiński wrote: HTML5 is not an application of SGML and I think it has been proven by now that it doesn't make sense to keep pretending it is (see story about SGML comment in Acid2). Yeah, I'm aware of that, the vendor complaints and subsequent change in Hixie's stance. I was careful in my previous post not to say compatible with or application of but use conversion to for exactly this reason. I don't believe I am 'pretending' anything. Just stating that diverging further from SGML for No Good Reason is pointless. (And yes, supporting a few odd websites that do this already counts as not a Good Reason, websites can always be fixed!) But also I think the scope of the original Acid2 furore was different, it was a case of dropping adherence to the SGML compatible syntax: !-- first comment -- -- another comment -- to something more like: token(!--); CDATA; token(--) On a related matter, does anyone know if WinIE correctly supports comments inside tags other than those that begin !-- ? e.g: !DOCTYPE html [ !ENTITY nbhy CDATA #8209; -- non-breaking hyphen -- ] object foo=bar-- this does foobar stuff -- bish=bosh -- this hits people over the head -- bash=bush -- this elects a democrat -- - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] Parsing: comment tokenization
On 7 Apr 2007, at 23:48, David Håsäther wrote: Markup starting with ! are declarations in SGML not tags. Yeah, sorry. I added the doctype bit after object and forgot to go back and amend the introductory statement. Consider the question to be tags and declarations that don't start with !-- :-) But what do you mean by support? From an SGML point of view, it's a markup error -- you can only have comments inside a markup declaration. I'm pretty sure nothing will break though. Really? I didn't realise that. Suppose it's why !-- is used and not just -- Well it's a shame, because it would have been really useful in HTML. And it reminds me of HyperTalk :-) Why do you ask? Because I don't have access to a Windows machine. I'd still like to know, if someone has WinIE and a spare moment to paste it into the DOM tree viewer. I would hope for the comments to be cut out and no empty attributes created. - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] Proposal: automatic cross-reference attribute: xref=
On 25 Mar 2007, at 23:13, Simon Pieters wrote: The current draft of HTML5 has an automatic cross-reference feature with the span, abbr, code, var, samp, and i elements, which would point to a matching dfn element. I don't see tens of thousands of web developers crying out for this kind of feature. Is it really necessary or is it just delaying and bloating the spec? - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] datetime - dateTime
On 24 Mar 2007, at 16:57, Anne van Kesteren wrote: The dateTime DOM attribute is spelled with an uppercase T: http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-79359609 I just encountered that while implementing longdesc support. The IMG attribute is lower-case, the DOM attribute is longDesc. At least they are consistently inconsistent :-) - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5
On 23 Mar 2007, at 02:27, Robert Brodrecht wrote: Just because most ... doesn't bother doesn't mean it ought to be removed. So let's not ignore elements because no one uses them. Ignore them because they are useless. I was thinking more along the lines of: 1) We start with a set containing all potential authors, human and robotic, past present and future. 2) We remove from that set the people and programs who don't care about or are not willing to learn correct methods of authorship, these people should have no say. 3) We then take a poll of every possible string value for new elements, and sort the result as a priority list, amalgamating words that mean the same thing. 4) We decide how many elements HTML should have (i.e. how complicated it should be/how hard for new people to learn), and cut the list at this number. 5) We then use this as the new HTML. That way I'm sure there would be 100 million votes for copyright and perhaps 250,000 votes for var, dfn, kbd etc. Mostly unused, not even deprecated, these elements bloat the spec, confuse lay authors (i.e. those not of a computer science background) and I feel would be better represented by a custom XML vocabulary. code is not useless And, frankly, you are wrong. Lots of places I go markup code with code You completely misunderstood. I was arguing against the need for var, samp et al. I.E. Markup *within* code/computer terminal representation, not against code itself. I welcome code to mark up blocks of code, but I don't think HTML should go further than that, if you want to mark up computer code that badly, use XHTML + some CodeML equivalent to MathML. I also believe it should be preformatted as well as monospace (white- space: pre; font-family: monospace;) by default. Indeed, if we were starting again I would probably make code block- level. Then again it's easier to write divcode (make a code block) than code style=display:inline; (make a code run) And works with non-CSS capable UAs/devices. I think the sample given for code in the spec should be wrapped in a div given that sample's inherent block-like nature. There could also be an example of it where just one word in a paragraph was marked up. But how can you justify the presence of kbd when so few people write content where keyboard input has to be represented? I've never met anyone who's hobby is writing computer software manuals in HTML. By contrast there are millions upon millions of people who watch television and discuss it on the internet. Why isn't tv-show an element? One only has to look at the examples given in the HTML5 spec to see how esoteric samp is: http://www.whatwg.org/specs/web-apps/current-work/#the-samp code isn't powerful enough as it is, in my opinion. I strongly agree. It's domain is also not clear enough either. Does morse code count? What about encoded strings? code type=rot13uryyb eboreg/code People who aren't programmers have a different understanding of the meaning of the word than we do. Confusing elements leads to both decreased and incorrect usage. I fear that in 100 years we'll be downloading free shampoo to our molecular synthesizers that will come wrapped in HTML samp tags. Well, only if the shampoo sample is output from a computer program. We do have to care about the semantics... No, you missed the point again. samp is short for sample. Misguided hair care people of the future will think their product sample counts as a sample and use it for that. Quite frankly most real-world/normal people (e.g. your greengrocer) don't care whether something is computer output or not, but they could very well benefit from product labelling up SKUs on their supplier's website, for example. We can't add elements willy-nilly without creating bloat though, and the dead wood has to be cropped to keep the tree healthy. Joe Clarke isn't calling for the removal of computer science elements. I am. Or at least their deprecation, a notice that they will be removed in future version of HTML. - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5
On 23 Mar 2007, at 13:17, Anne van Kesteren wrote: On Fri, 23 Mar 2007 13:40:47 +0100, Nicholas Shanks [EMAIL PROTECTED] wrote: Mostly unused, not even deprecated, these elements bloat the spec, confuse lay authors (i.e. those not of a computer science background) and I feel would be better represented by a custom XML vocabulary. How does that help anyone? Putting them in a custom XML vocabulary drops all semantics directly. (Unless a search engine does some heuristics on element names I suppose.) Custom XML vocabularies are really not something you want to have on the web as its implied they have no known semantics. Not true. XHTML, MathML and SVG are all custom vocabularies with very widely known semantics. There's nothing preventing a future CodeML syntax from being understood by Koders and Google Code Search. - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] Markup for external content
On 23 Mar 2007, at 17:59, Henri Sivonen wrote:
pretending that applet doesn't exist won't make applets
disappear. :-(
Perhaps not, but this will:
applet { display: none !important; }
:o)
- Nicholas.
smime.p7s
Description: S/MIME cryptographic signature
Re: [whatwg] source
On 23 Mar 2007, at 20:47, Maciej Stachowiak wrote: I agree the repetition of source/src is a little weird. and name the new element something like alt I don't like abbreviations such as alt and src. The use case is uncommon enough that alternate wouldn't be too much of a burden to type and ought to prove more readable. Perhaps reusing li like that is too cute How about: playlistol liaudio src=foo type=...Audio fallback/audio/li livideo src=bar type=...Video fallback/video/li /ol/playlist User agents that don't support playlist, audio and video just get an ordered list of fallback text. UAs that do support them also benefit in being able to negotiate each variant individually instead of getting whatever collection of media files the playlist movie decides upon. And perhaps playlists with a ul child can play the media in any order, not necessarily source order, presumably whatever item becomes available first. But I have been arguing against element proliferation in another thread and here I am suggesting new ones :-) - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] Apple Proposal for Timed Media Elements
On 22 Mar 2007, at 00:08, Maciej Stachowiak proposed: CSS Timed Media Module HTML Timed Media Elements • On volume: The volume property is currently inconsistent in the string names defined: http://webkit.org/specs/Timed_Media_CSS.html#propdef-volume Value: reads silent | soft | medium | loud | x-loud but the definitions below use the terms silent, low, medium, high, full- volume. I think this should match css3-speech's voice-volume property: http://www.w3.org/TR/css3-speech/#voice-volume Volume has the range 0-100 in the DOM interface, but 0.0-1.0 in CSS. These should be consistent (I favour zero to one and allowing percentages). You may also want to name it media-volume, on analogy with voice- volume. (or change css3-speech to use just volume) • On media state: I think that the ERROR state attribute should have a value of -1 not +1 since it is a worse state than uninitalised—you know it's bad rather that being unsure (and the state constants be defined as signed rather than unsigned) http://webkit.org/specs/HTML_Timed_Media_Elements.html#state-attributes Should the DOM attribute be called mediaStatus or mediaState? I think the terminology should match regardless of whether status or state is used. Should media-play-state be renamed to avoid confusion with values for mediaStatus? - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] Full screen for the video element
On 22 Mar 2007, at 14:16, Gervase Markham wrote: Martin Atkins wrote: Perhaps you and I have different ideas about what is meant by full screen, but why would a page need to hide anything when the video is full screen? The page itself won't be visible, because the video will be taking up the entire screen! My thought was that it would be the same function as the current full screen that the browser has. I.e. the page says For full- screen, press F11. The user presses F11 and the browser makes the window full-screen, Does this hide the menubar/taskbar/widgets, darken other screens (I have three) or anything along those lines, and resize the browser window? To me full screen mode for video would not alter the browser window size, instead it would cover the screen in a new window and draw just the video into that. The browser window would be left untouched below (though the video may no longer be rendering into it). I would also like to be able to drag the full-screen video to a secondary monitor, switch back to the browser window and keep browsing (perhaps in another tab or read the rest of the page). The video would keep playing full-screen on the other screen until I closed the originating tab, the video ends, or I stop playback. - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] whatwg-legal
On 22 Mar 2007, at 16:11, Robert Sayre wrote: On 3/22/07, Gervase Markham [EMAIL PROTECTED] wrote: Would it not have made more sense to at least have asked the WHAT-WG No. I think you're wrong and clearly I'm not alone. In fact I think legal matters *should* be discussed here and advocate that no-one join your little splinter group. Certainly using their name without permission was exceedingly poor judgement. Luckily for you though, you created it at MSN, preventing Hixie from walking down the corridor and shutting the group down. - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] video element feedback
On 22 Mar 2007, at 20:53, Silvia Pfeiffer wrote: Sorry to jump into this conversation at such a late point, but I only just joined the mailing list. About 8 years ago, we had the idea of using fragment offsets to start playing from offsets of media files. However, in discussions with the URI standardisation team at W3C it turned out that fragment offsets are only being seen by the UA that sends them, so they will never reach the web server. There's a good discussion about that here: http://1997.webhistory.org/www.lists/www-talk.1993q2/0551.html (read through the rest of the thread for more info) This makes it impossible to use them for play from this offset since obviously the offsetting should be done by the server and avoid downloading the bunch of data that comes before the offset point. But it doesn't stop the UA from taking cues from the markup (such as my gegenschein example from yesterday) and generating a query such as ?start=17:33. They don't have to request the exact value of the src attribute. - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5
Continuing today's flood of emails from me to this list, here's another. Note: I never bothered to read this thread the first time, but since Henri has brought to the top of my email client again, I started from the beginning. I want to comment on the eight bullets given at: http://www.alleged.org.uk/pdc/2003/xhtml2-cite.html (a page linked from Joe Clark's original article) These aren't that well thought through, I'm just throwing them out to be peed upon. • 1 and 2 are both proper nouns, names of things. These could be addressed with name with predefined classes book, movie and ship producing italic output (and person, animal, product etc not doing so) More thought would be needed here, like perhaps only applying for :lang(en) parent elements, such as: html lang=enpMy favourite film is name class=movie lang=frAmelie/name. I have it on abbrDVD/abbr./p/html • Bullets 3 to 6 could be addressed with a term element, default rendering italic (not related to dt). You can apply any adjective you want to term and it seems to remain valid: foreign term, mathematical term, new terminology, etc. It would seem quite versatile yet remain semantically useful without becoming too general. • Bullet 7: I think people marking up computer code in HTML are completely wasting their time. Most sample code I have seen doesn't bother. e.g. some random OpenGL sample code: http://developer.apple.com/samplecode/Red_Rocket/listing4.html http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=Mac_OS_X The usage case for this vs. usage of HTML for the rest of the internet is insufficient to earn the right to be in HTML. • Bullet 8: We already have em On 22 Mar 2007, at 21:25, Henri Sivonen wrote: On Oct 30, 2006, at 22:33, Ian Hickson wrote: On Sun, 29 Oct 2006, Henri Sivonen wrote: FWIW, I think samp and kbd don't deserve to be in HTML and I am not convinced that the use cases for var could not be satisfied by i. I'm lukewarm on all three, but the cost to keeping these is probably slightly less than the cost to removing them, so I'm tending towards keeping them... FWIW, var is used the most of those three, and samp the least; they are all three used more often than bdo or ruby, at least in the sample of several billion files I last made. (We're talking in the 0.01% to 0.05% range here.) I tend to agree. But then they should not be used as a basis for arguing anything about the design of HTML5 or as bases for analogies for including new semantic elements of similar kind. I hate them :-) I would love to see var samp kbd et al. officially deprecated. In fact, we could just deprecate anything that was in HTML 1.0 and hasn't earned itself more than 1% usage. No-one would miss them. (And if they do they can author in XML.) I think elements should earn their place in the standard and get kicked out if the use case is too obscure or there is a more appropriate markup language available (MathML, DocBook). I fear that in 100 years we'll be downloading free shampoo to our molecular synthesizers that will come wrapped in HTML samp tags. - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] video element feedback
On 23 Mar 2007, at 01:30, Sander Tekelenburg wrote: (Note that a mechanism to allow authors to define anchors in videos is not a solution, because it's then still the author who is in control. What I'm suggesting is about giving the user control.) Can't we have all of: 1) A way for authors to match up timecodes with fragment identifiers in the fallback content 2) A way for UAs to skip to that time code if a fragment identifier is requested and it's contained within fallback the UA isn't displaying 3) And a way for users to link to timecodes that aren't marked up at all. the client doing the request should be smart enough to know to escape the colon Wikipedia section IDs have lots of escaping, but it's all done by the wiki server, not the UA. I don't know if this is because UAs can't be trusted to get it right or not. I'm getting the impression from RFC 3986 that it is up to the app... RFCs are one thing, implementations are another. - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] require img dimensions to be correct?
On 21 Mar 2007, at 09:37, Henri Sivonen wrote: OTOH, the left/right alignment of table cells *is* often tightly coupled with the cell data, which suggests that the cell alignment attributes should not be dropped. Alternatively it could just be allowed on the col and colspan, where it would affect td cells (but not th cells). Just a random thought. - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] video element feedback
On 21 Mar 2007, at 12:43, Sander Tekelenburg wrote: Something else concerning first-class Netizenry: I'd like to see the spec to require UAs support implicit anchors, so that one can link to a specific startpoint: URL:http://domain.example/movie.ogg#21:08, to mean fetch the movie and start playing it at 21 minutes 8 seconds into the movie. (Or better yet, if this can be achieved reliably, don't fetch the entire movie, but only from 21:08 on.) Well besides the fact that fragment ids cannot start with a number nor contain a colon, you have to consider the problem of multiple unequal representations. In this example equivalent content is not at the same time offset. Clicking the link should take you to the relevant place whether the UA is rendering the video, the audio or the transcript: pYou a href=#gegenscheinsee the gegenschein/a if you really squint./p video src=video-with-visual-splash.mpeg fragment-position for=#splash time=00:00 / fragment-position for=#gegenschein time=02:13 / audio src=audio-with-spoken-splash.aiff fragment-position for=#splash time=00:00 / fragment-position for=#gegenschein time=02:24 / !-- transcript fallback -- section id=splashpProduced by Foo Corporation/p/section … section id=gegenschein … /audio /video - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] video element feedback
On 20 Mar 2007, at 21:50, Benjamin Hawkes-Lewis wrote: Ian Hickson wrote: However, I think if object is so widely derided by everyone, than I think it needs to be depreciated sooner rather than later. I have seriously considered doing this. Unfortunately I don't think we can actually do it given the large amount of legacy content, e.g. tutorials for how to embed flash which encourage use of object. In the unlikely event that object be in any way discouraged, can we ensure we allow element level fallback content for img (or some replacement element) as opposed to the alt attributes we're currently lumbered with and the longdesc attribute that WHATWG has done away with? I asked for the resurrection of HTML+'s imagefallback/image element last month. The reasons I cited were exactly the same as the reasons being given now in favour of the video element, however I was told (paraphrasing) Why bother, you can just use object and That would break existing implementations (though no such implementations were cited). So again, I ask for an image element to replace img. Benefits include: • As video would cater for video/* MIME types, image would cater for image/* • The alt and longdesc attributes can be part of the fallback content, allowing markup. • You don't have to provide a type attribute and match on: object [type^=image/] • and more… - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] require img dimensions to be correct?
On 17 Mar 2007, at 23:28, Andrew Fedoniouk wrote: I think that in most cases will be better if we could package complex pages into zip envelopes and deliver them in the whole. That would be real solution of jumps. And img width=... height=... is a palliative. I have an open bug with Safari requesting support for the multipart/ mixed Content-Type. This would provide the ziped content you request (and you can use a Transfer-Encoding to compress it before sending) I have a demo page at http://web.nickshanks.com/browsers/safari/ multipart correct rendering at http://web.nickshanks.com/browsers/safari/ multipart2 - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] Resurrection of HTML+'s image (was: video element feedback)
On 21 Mar 2007, at 00:27, Simon Pieters wrote: I asked for the resurrection of HTML+'s imagefallback/image element last month. I was told that would break existing implementations Existing implementations include at least: * Internet Explorer * Firefox * Opera * Safari The image start tag is parsed as if it were img, so you would get both the image and the fallback with HTML+ markup. Existing content rely on this behaviour, which is why it was added to the Parsing spec (see A start tag whose tag name is image, and see comment in source). So what's the problem? Content with a doctype of !DOCTYPE html or !DOCTYPE htmlplus is treated correctly, and content without a doctype is handled in quirks mode, where the UA can look for /image and if found in a suitable place, treat the start tag as image, or if not found, treat the start tag as img. Any content using image in strict mode with another HTML doctype is broken anyway, so it doesn't really matter how that looks. - Nicholas. smime.p7s Description: S/MIME cryptographic signature
[whatwg] Navigation Lists — A different use fo r MENU, and two errors
Given XHTML 2.0's idea of an element for navigation list (using nl as the tag [1]), it occurred to me that menu, deprecated in HTML 4 but resurrected in HTML 5, would be entirely suitable for this purpose and fully backwards compatible. From what I can gather, this was the intended purpose of the element in the first place (not mimicking of OS menus/toolbars). It was little-used probably though lack of awareness. I suggest that a new type, navigation, be available for the menu element. It's default rendering would be unchanged from HTML 4 (essentially, the type would be a no-op) but used to explicitly declare destination-oriented rather than an action-orientated menus. This would be in addition to rather than instead of the nav element, who's behaviour in HTML4 UAs is that of div rather than ul. (And be backwards-compatible, something nav isn't!) e.g. menu type=popup !-- not a popup menu, actually declaring contextual menu items -- liBold liItalic liBold and Italic /menu menu type=toolbar !-- button-like behaviour -- liEmbolden liItalicise /menu navmenu type=navigation !-- contains some links -- lia href=boldTypeface weights/a lia href=italicCursive writing/a /menu/nav In particular, it seems pertinent for accessibility. For example, this survey seems to highlight that blind users cannot easily distinguish between menus and submenus: http://www.usability.com.au/resources/source-order.cfm (I highly recommend reading that article !) Allowing header elements within the menu content model would alleviate this. Currently the label attribute is used for this purpose, which has all the failings of an attribute discussed at length in other threads, but most importantly does not get seen by users with screen readers! I also think that the popup type should be renamed contextual. What is known as a pop-up menu is created by using the select element. Further, I am concerned about the backwards-compatibility of menus inside menus. The current spec says that if the submenu contains no label, it should render in line with the previous items. This contradicts HTML ≤ 4 which says that menus inside menus should act the same as ULs inside ULs. (i.e. indent; create a submenu). [1]: http://www.w3.org/TR/xhtml2/mod-list.html#edef_list_nl - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] Video proposals
Discussion on aspect ratio:
You may want to consider aspect ratio too: ratio=preserve being
default, ratio=1.333 could indicate 4:3 or get tricky and accept
16:9 for precision reasons.
Wouldn't we simply always want to use the authored size?
Do videos encode what size they are best displayed in? I hate
entering height and width for images.
The reason I requested this is because:
1) If you specify both a width and a height, video content that
doesn't match that gets distorted.
2) If you want an element to have a fixed width, but variable height
dependant on the aspect of the video, or fixed height and variable
width, yet still have a non-zero initial value for the variable
parameter (so that the video element occupies some screen area),
you cannot achieve this without distorting the final image by setting
both width and height.
3) Thinking about it more, the ratio should be explicitly advisory
and only valid until the downloaded video can provide it's own width
and height.
I envisage:
video src=foo width=386px aspect=59:54/video
pSome content below the video/p
Then, when the video is finally downloaded and it's inherent
dimensions (and thus aspect ratio) are known, re-layout can occur if
the aspect values don't match, but more importantly can be avoided if
they do.
The width given is an integer number of CSS pixels, by providing an
aspect ratio, the UA can calculate the resultant height in device
pixels without the user having to provide a height and associated
rounding errors (or plain mistakes). The example above has an
irrational height.
4) Only two of {width, height, aspect} can be specified on any video
element.
- Nicholas.
smime.p7s
Description: S/MIME cryptographic signature
Re: [whatwg] Video proposals
On 16 Mar 2007, at 15:32, Shadow2531 wrote: .loop, .startpos loop = false | true autostart = true | false startpos = 0 | specified pos Could you elaborate on the use cases for these? video src=VideoIWasWatching.ogg param name=startpos value=value gotten from cookie where I left off at /video The downside of that is sites have to implement a cookie system. I don't want to do that on my own site and many personal website owners won't know how to either. For the above usage case, I don't see why remembering where you left off can't be a user-agent feature rather than part of the specification. Granted that would fail if you switch browsers but people don't do that much. All said, it would be very useful if the startpos param could be returned to the server when starting the download, or when scrubbing forward into parts of the video that haven't yet downloaded. as that would help avoid using bandwidth unnecessarily. I see two ways to do that over HTTP: 1) As a HTTP header 2) In the URL There is also currently this RTSP URL format understood by RealPlayer: rtsp://rmv8.bbc.net.uk/french/fre0600.ra?start=%2220%22 Other formats may understand other parameters, or not define startpos as an integer number of seconds, but use hrs:mins:secs etc. How would the UA then send the startpos if differing content types used different mechanisms? - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] Attributes vs. Elements
On 12 Mar 2007, at 20:19, Andrew Fedoniouk wrote:
Case:
td a href=1.htmxyz/a/td
td a href=2.htmxyz-xyz-xyz/a/td
is perfectly valid from some abstract semantic machine
point of view but for human these two cells are not
equal. At least hit area is different. And visual perception too.
All you need to do is add this to your CSS:
td a:link { display: block; }
and the whole cell content area will become clickable (i.e. the area
interior to the padding. don't use padding on the cell if you want to
run the clickable area up to the cell's border)
Even now you can use get/setAttribute methods to get/set 'href'
attribute to any element. So where do you see the problem?
But that doesn't make any of them clickable, because they are not
anchor heads.
I do not really understand this too:
browser implementations have an implementation class per element
Most HTML implementations use a class hierarchy whereby each HTML
element is represented by a distinct subclass of some abstract base
element representation. To move href onto every element would require
moving the hyperlink functionality into that base class rather than
having it in the anchor subclass.
For some browsers this could be quite easy, for others it would be
deceptively difficult.
- Nicholas.
smime.p7s
Description: S/MIME cryptographic signature
Re: [whatwg] video element proposal
On 2 Mar 2007, at 10:01, Gervase Markham wrote: I think a base format is vital. With img we had de-facto standard formats because of what the first browsers supported. It took ages to get another one added (PNG) and it wasn't widely used until browser support firmed up. If a base format can't be guaranteed, people will just keep using Flash, which works almost everywhere (currently, with proprietary software only, but keep an eye on Gnash). It may be a good idea to specify an either-or-both policy and include a second video format, allowing vendors a little freedom as to which to implement. Dirac (dirac.sf.net) seems like a good alternative format, but I don't know what licenses are acceptable to closed-source browser vendors. They say: As a defensive measure the BBC has applied for patent protection for some techniques that are, or may be, used within Dirac. Our purpose in doing so is to provide protection for Dirac from spurious patent suits by other parties. Under the terms of the MPL we have licensed these patents irrevocably and royalty free for use within the Dirac software. Our intention is that Dirac code be used as widely and as freely as possible. This is why we have allowed re-licensing under the terms of the GPL and LGPL licences. And on Theora: Theora is coming on very nicely, and has an impressive, well-defined spec. We think we have much better compression performance, but you can't have too many free codecs. We intend to pack the Dirac elementary stream into MXF, which has lots of useful features. That doesn't preclude it packing into Ogg (or Matroska, or anything else) as well, and it's probably a good idea to have a variety of packing formats. indeed! - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] href attribute
On 2 Mar 2007, at 17:00, Alexey Feldgendler wrote: Likewise, HTML has a to explicitly express the semantics of a hyperlink. I don't see how the language would benefit from the ability of turning any element into a link. The main use I would put it to is on li elements, especially tables of contents—the usage would be hyperlinks, not buttons. it also helps remove redundancy when you have any two tags opening and closing at the same place, such as aabbrfoo/abbr/a (or abbrafoo/a/ abbr — which is better anyway?) - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] video element proposal
On 1 Mar 2007, at 11:56, Anne van Kesteren wrote: That's one of the reasons a dedicated element is better than reusing the object element. All the new video specific APIs would otherwise have to be defined for all possible things the object element can represent (images, nested browser context, video, audio, plugins, etc.). Given that the object element is already a nightmare for implementors... Would I be right in thinking of video as inheriting from/a subclass of object then, to draw an OOP analogy. Or would they be more like siblings? Secondly, I think of ‘video’ as a sequence of visual frames with no audio. I presume you mean something more akin to what I call a movie container, with a video track, multiple audio dubbing tracks in different languages, subtitles or graphical overlays, c. If so, do you think the name could be altered to reflect this? Thirdly, are you intending for there to be audio counterpart? I assume you want the width and height attributes to be used only for specifying the original width and height the video was made at, and css should be used to set the width and height to a % or px etc.? Yeah, maybe. I was thinking about something along those lines, but I couldn't really figure out how it would work. Video streams/files already contain their native pixel dimensions, and as Henri said, you never know what you're going to GET. A better attribute would be scale which takes a floating point value, defaulting to 1.0 (should probably have a corresponding CSS element too, which we could apply to other things that have native dimensions like still images). This would work well with max-/min-width. You may want to consider aspect ratio too: ratio=preserve being default, ratio=1.333 could indicate 4:3 or get tricky and accept 16:9 for precision reasons. - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] XSLT: HTML 5 -- HTML
On 9 Feb 2007, at 07:47, Karl Dubost wrote: Le 8 févr. 2007 à 20:17, Nicholas Shanks a écrit : On 6 Feb 2007, at 07:57, Karl Dubost wrote: http://www.w3.org/MarkUp/HTMLPlus/htmlplus_1.html I wish the imagefallback/image tags had made it through the years. It's so much better than img alt=blah and doesn't suffer from the self-closing-tag-in-html problem. like object? Yes, like it, but with a different name. A nicer name than IMG. One with three vowels. One that only accepts image/* content types. One with a more specific usage that can be controlled independently of OBJECT through CSS 1/2. - Nicholas. smime.p7s Description: S/MIME cryptographic signature
[whatwg] IMAGE element (was XSLT: HTML 5 -- HTML)
On 9 Feb 2007, at 15:51, Benjamin Hawkes-Lewis wrote: Nicholas Shanks wrote: Yes, like OBJECT, but with a different name. A nicer name than IMG. One with three vowels. One that only accepts image/* content types. One with a more specific usage that can be controlled independently of OBJECT through CSS 1/2. Strictly, you don't really need a second element for independent selection. CSS 2: object[type=image/jpeg], object[type=image/gif] ... ad infinitum. I don't consider that wise, because: a) you'd have to list every possible image/* combination that exists or could be invented in the future b) you'd have to add a type attribute to the element, which implies i) you have control over the HTML (in user.css it wouldn't work) ii) you ‘know’ what content type the server is going to return Draft CSS 3: object[type^=image/] better (which is why I didn't mention CSS3 originally), but point (b) above still applies. The basic point of replacing IMG with IMAGE rather than replacing it with OBJECT was (would be) specificity. The image element could now be defined as a subtype of the object element for that most common usage case of including pictures on a page. The other thing is that IMAGE could be *block level* by default, and wouldn't cause the extra line height whitespace problem that inline images can cause when misused. IMG would still be available for simple inline images like img src=/emoticons/smilie alt=:-) Further benefits: longdescs could be included as a hyperlink at the end of the normal fallback text. Importantly, explicit inclusion in the HTML5 spec would make more people aware of the kind of behaviour and benefits that have always been available through object but that few people use (myself included, I must admit). I was originally just making an off-the-cuff hostile remark about IMG, but the more i think about it the more I dislike them pesky and restrictive alt attributes! - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] De-emphasis
On 9 Feb 2007, at 17:19, David Latapie wrote: - small: It does not cope well inline. I (almost) never use small in a paragraph; I use it for one-liners, e.g. smallsource:/small or smallNo this is a long post, right?/small Agreed, when I use small, which these days is just for things like post author and date on my blog, it's *always* wrapped by a p tag and is included only because certain text-based browsers render it in a darker green than body text on a black bg (basically a sort of opacity: 0.5 !). I'd propose, then, that inline visual de-emphasis may be impossible. (I'd suspect the same for audio de-emphasis -- would the smart screen reader whisper it? Wouldn't that, too, draw attention?) voice-stress:reduced come to my mind. I'll come further by saying that, here, aural is better than screen Indeed I was mostly considering marking up an aural origin for de- emphasis rather than a printed origin. I agree that there's not really a precedent in Western print for something like this beyond parentheses (though I can't speak for Arabic or Asian print), but there *is* a clear usage case for transcribing speech. I think the best use case for dem would be (in western typography, again) to wrap around parenthetical statements such as the one in the sentence. However, as the problems with q have demonstrated, it cannot be assured that all user agents would support adding parentheses from Day 1, and as such dem should have NO default visual styling. voice-stress: reduced is fine for aural though. However you could say that it's the aural renderer's responsibility to understand parenthetical content, whether marked up or not, and say it with reduced stress. This leaves de-emphasis as purely a theoretical tag for markup purists and without any tangible benefit for most HTML authors. - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] The m element
On 8 Feb 2007, at 15:23, Leons Petrazickis wrote:
In the Western world, the standard for highlighting is a neon yellow
background. I submit that a much better name for m is hi
(hilite, highlite, highlight).
I don't like the look of hi — it doesn't tell me what it does
very well. Maybe it stands for Horizontal Italic, or is some kind of
markup greeting element:
File: hi
Browser: hi
File: i have some html for you
Browser: cool
It seems to impart too much of a visual origin too. Like b andi did.
I still think mark would be better. It's short enough not to be
annoying, and long enough to be self explanatory.
People don't necessarily mark
text much -- if anything, mark implies underlining, circling,
drawing arrows...
...or highlighting with a fluorescent marker pen!
The default styling of hi would be a neon yellow background.
Google's choice of #66 could well be suitable.
If you set the background colour you MUST set the foreground colour too!
mark { background-color: #FF6; color: black; }
- Nicholas.
smime.p7s
Description: S/MIME cryptographic signature
Re: [whatwg] The m element
On 8 Feb 2007, at 18:00, David Latapie wrote: Problem with mark/m is that its meaning is confusing. I don't think it's any more confusing than hi would be. See below... And still don't see any difference with em or strong. How would you pronounce an important word? How would you pronounce a highlighted word? Even on the semantic level I can't see the point. Try to compare it with ins and del, it's an element concerned with editing a document post-authorship, not marking up the document's inherent structure. I don't think it would be confusing *provided* it was listed next to ins and del on all those ‘Learn HTML5 in 24 Hours’ sites/books/ specifications that people will actually learn about it from. Doing this would allow 99% of such people to ignore it like they currently ignore ins and del, and therefore won't confuse anyone. - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] XSLT: HTML 5 -- HTML
On 6 Feb 2007, at 07:57, Karl Dubost wrote: unlikely. div and span elements didn't exist in HTML+. http://www.w3.org/MarkUp/HTMLPlus/htmlplus_1.html Ironically I was just reading that earlier today, then saw your post! (I hadn't been reading this thread.) I wish the imagefallback/image tags had made it through the years. It's so much better than img alt=blah and doesn't suffer from the self-closing-tag-in-html problem. - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] De-emphasis
On 8 Feb 2007, at 22:31, Henri Sivonen wrote: On Feb 8, 2007, at 21:09, Nicholas Shanks wrote: de-em, de-emph, subdue or other new element What would the default visual presentation be? One or more of: none (i.e. same as span: 'inherit everything') opacity: 0.8 font-size: smaller parentheses ::before and ::after (in a text browser, say) - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] The m element
On concern that we would be 'wasting' such a short element name for such an esoteric usage, why not call it mark instead? - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] contenteditable, em and strong
Having come in to this conversation half way, I'd like to give my opinions. In the following 'default style' means in the UAs style declarations for all documents of the language. There should be three emphasis elements: em Increases emphatic semantics by one level. *No* default rendering style for visual media, default rendering for other media not specified. i Equivalent semantics to em. Default rendering style for visual media is a language-dependant alternative glyph set of the same font family and weight (e.g. italic/курсив, oblique, カタカナ). Default rendering style for other media not specified (at least the same as em). b Equivalent semantics to em. Default rendering style for visual media is the same font family and glyph collection, but higher weight. Default rendering style for other media not specified (at least the same as em, perhaps louder for aural). The strong element is deprecated, replaced by nested levels of em or it's visual-specific variants. Thus where visual presentation is important, i and b can be used semantically (they are equivalent) and em ignored. Where visual presentation is not important, em can be used without concern for what i should sound like. The basic point is that em has no default rendering style, discouraging it's misuse for i want italic text and people tell me i is bad these days, so i'll use em. - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] return lowercase hex values for fillStyle and strokeStyle
On 5 Sep 2006, at 12:54, Charles McCathieNevile wrote: Instead of returning an uppercase six digit hex value I suggest returning a lowercase value for compatibility with what UAs (including IE) currently do It may be the right decision on compatibility grounds, but other than that lowercase hexadecimal digits (0-9, a-f) are almost always a bad choice, because a, c and e have no ascenders like every hindu-arabic decimal digit has and thus make the number harder to read. This obviously does not apply to fonts with old- style numerals aka. text figures, where 0, 1 and 2 have neither ascenders (like 6 and 8) nor descenders (like 3, 4, 5, 7 and 9), but those are rather unlikely to be used in a programming environment. I believe this, but I suspect that the gain in compatibility is well worth the minor loss in efficiency for people who are hand- coding. I disagree, and always prefer uppercase hex digits to lowercase ones, it makes the numbers easier to read IMO. - Nicholas.
[whatwg] css3-fonts: New values for generic font families
I wish to submit two proposals for changes to the generic font families built into CSS. If someone could please forward these to whomever is currently working on the css3-fonts module, I would be much obliged. 1) That monospace and it's new inverse proportional be independent of the other generic families, and that both a generic and monospace/proportional (in either order) be specifiable together. This should be followed by a lone CSS2 generic for backwards compatibility. If not present, proportional should be assumed. Examples: Old:- font-family: Courier, Courier New, monospace; New:- font-family: Courier, Courier New, serif monospace, monospace; Old:- font-family: Monaco, monospace; New:- font-family: Monaco, sans-serif monospace, monospace; Old:- font-family: Hoefler Text, Georgia, serif; New:- font-family: Hoefler Text, Georgia, proportional serif, serif; 2) The addition of two new generic family classes for the Latin script, namely: blackletter (including fraktur, gotisch, schwabacher, rotunda, old english, c.) uncial (including insular, irish, c.) Blackletter is by far the most important of these, as it is quite common (much more so than 'fantasy') yet there are few universal blackletter fonts on all systems. Whilst it is often seen that a web designer will append Arial before the generic family—making the generics almost useless in that regard—due to the lack of universal fonts for either of these generics a user agent would likely find it falls back to them much more often than for 'serif' and 'sans-serif'. - Nicholas Shanks. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] css3-fonts: New values for generic font families
Hi Håkon, thanks for replying. Why not just follow the guidelines in the CSS3 font module?: Ahh, I didn't see there were instructions on the module itself on where to send suggestions, and it doesn't give the main author's name (just the CSS2 authors and Tantek… et al). I was on that css list a few years ago. It was full of spam (people asking simple how do I do x with CSS? questions) and no-one paying attention to my suggestions for future implementations so I abandoned it. While I appreciate the convenience this new functionality may have for designers wanting to see text in (say) blackletter, the inconvenience for browser implementors will be disproportionately large. Where will they find these fonts? I don't think there would be any inconvenience. Either they can allow the user to select a font from all those available, or it can filter down using a list of keywords such as the ones I suggested. They could also hard-code a few common fonts that don't get picked up by the keywords. Perhaps a combination of the two, with filtered blackletter fonts at the top of the menu, a divider, then all the rest. The same can go for script font, filtering the list against keywords such as script, hand, child, pen, felt, crayon Will they have to ship fonts with browsers? Not any more than they do currently, which is none. :-) The current number of generic font families (5) is already stretching it; one might argue that even fantasy and cursive should be dropped as many systems don't offer fonts in these categories. I don't think there's much use for fantasy, as what exactly constitutes a fantasy font was never clearly defined. And if cursive is removed, it should be replaced by more descriptive variants such as calligraphic and handwritten A better way to support interesting fonts is -- IMHO -- for browsers to start supporting TrueType Webfonts. I have been campaigning for better @font-face support for years too, and I will implement it in WebKit once all the more pressing typography and CSS bugs that bother me are taken care of (like using more than two font weights, proper small-caps and being able to switch between lining and text numerals). The biggest problem I see with using @font-face currently is that not many fonts provide the correct Panose 1 numbers, making matching to a close substitute very hard. All the concern about violating copyright mentioned in the Mozilla bug on this rule are IMO invalid, as there are already so many more interesting way to violate copyright than this! By the way, if you're looking for someone to implement this and other CSS stuff in Opera, I am currently seeking employment. I have been having difficulty getting anywhere with Apple due to the United States' negligible work visa quotas. - Nicholas. smime.p7s Description: S/MIME cryptographic signature
