Re: [whatwg] Proposed additions to ClientInformation interface
Tuesday 08 of July 2008 14:45:23 Maciej Stachowiak napisał(a): The way I think of standalone(*) Web applications is that they should work well in the browser context, but be able to provide progressive enhancement when in standalone mode. For example, native applications have custom icons in the Dock under Mac OS X, but pages in a browser window do not, so we let Web applications have the ability to customize the icon only when running in standalone mode. Pages in a browser window have the favorite icon. Chris
Re: [whatwg] Proposed additions to ClientInformation interface
Tuesday 08 of July 2008 05:10:46 Mark Finkle napisał(a): On Mon, Jul 7, 2008 at 6:04 PM, Ian Hickson [EMAIL PROTECTED] wrote: On Fri, 27 Jun 2008, Brady Eidson wrote: * Sites want to offer a way for users to opt into a standalone mode (can we offer a link to download one of these standalone Web apps?). Basically, to offer a way to bookmark the page as a standalone app instead of as a bookmark that opens in the browser. link rel ? Not really, it would abuse the LINK element. [snip] * It shouldn't be something that appears in the browser's UI, since browsers have basically run out of room. disagree. it will depend in browser UI anyway for the confirm prompt The prompt would be presented in a modal window, therefore it would not use chrome space. Chris
Re: [whatwg] Supporting MathML and SVG in text/html, and related topics
Dnia 10-04-2008, Cz o godzinie 09:51 +, Ian Hickson pisze: On Sat, 4 Nov 2006, Paul Topping wrote: Elements whose namespaces aren't known should be handled like any other unknown HTML element. I believe the common way for user agents to handle an unknown element is basically to ignore the tag and its attributes and treat any text between start and end tags as if the tags weren't there. Namespaces do not present any new challenge in this area. Bogus namespaces are no more of a security risk than bogus HTML tags. It is only the ones that ARE processed by the user agent that represent potential security risks. The problem is legacy content like: html foo xmlns=bogus namespace ...rest of HTML document... We don't want to make the whole document get ignored. An example of such a tag is Microsoft HTML application indicator which is empty by design. But how does Paul’s recipe amount to ignoring the whole document? If anyone is actually reading this 3363 line e-mail, I'm impressed. Please do let me know that you read this. I do not do bungee jumping though.
Re: [whatwg] Request: Canvas Tag CSS
Dnia 08-04-2008, Wt o godzinie 12:39 +0200, Thomas Broyer pisze: On Tue, Apr 8, 2008 at 11:37 AM, Greg Houston wrote: Between Anne, Thomas and I, we have clearly shown that the individual shapes within a canvas element can indeed be effected by CSS at the time of their rendering and re-rendering(such as in an animation). at the time of their rendering is the key. You cannot they are affected by CSS, it's just that your script reads the current property value from a stylesheet and uses it to draw the shapes. Affected by CSS would mean (at least that's my interpretation) reacting to CSS changes (document.styleSheets[0].cssRules[0].style.color = black; or simply selecting an alternate stylesheet from your browsers view menu). Maybe you could say initialized from CSS... It is, however, far more convenient to initialize from JSON. I have proposed a solution that greatly simplifies effecting canvas shapes with CSS. Anne and Thomas have offered two work-arounds, one of which is rather complex, and the other is a strange hack and only slightly less complex. Anne also proposed you the Simplest Thing That Could Possibly Work: use search/replace in both CSS and JS. Want to change #123456 into #567890? search #123456 and replace with #567890. Search for #123456 and replace with preferred_colour_for_feature_X() I understand what you're asking for, I just don't see the need, as it seems to me it'll do more harm than good: as soon as designers will start to style your canvas using CSS, they'll start using properties that you don't support in your drawing script. I mean, as Matthieu said, canvas is imperative while CSS is declarative, so most of CSS cannot be used with canvas. The only thing you can do is read values from the CSS and use them in your canvas script. In my opinion, you'd rather have a script consisting only of variable definitions (à la *.ini or *.properties files) and have your designers only update this file (and never touch nor even see the script responsible for the actual drawing). I would recommend using functions instead of variables, or using JSON for the whole feature set. Chris
Re: [whatwg] INS and DEL in lists
Dnia 28-03-2008, Pt o godzinie 13:29 -0500, Tab Atkins Jr. pisze: On Fri, Mar 28, 2008 at 12:07 PM, Krzysztof Żelechowski [EMAIL PROTECTED] wrote: Dnia 28-03-2008, Pt o godzinie 09:12 -0500, Tab Atkins Jr. pisze: And the original problem can be solved using CSS2; I only wanted to bring a similar example: HTML poorly supports interleaving unrelated markup streams. Please, elaborate. The reason this is a problem is because it *can't* be well-solved with CSS. How about LI CLASS=DEL ? Conveys no semantics, unfortunately. Non-css browsers will have no way of knowing that this is a deleted item. That's the whole point of having a del element in the first place. On the other hand, mixing together lists and tables doesn't seem to have any good semantic interpretation. How about bilingual lists that have to be aligned in two columns? The reason I objected to that example was because you'd pretty much just be jacking the *display* of ol for your own purposes, without regard to the semantics. If you just want something numbered without giving it proper list semantics, hand-number it or use generated content. On the other hand, once I have a list, I can put it into a table cell. Then I translate the list into the neighbouring cell and I realise that the translations do not align. According to your recipe, I have to convert the original list structure to something else, something that older browsers do not support well. I feel frustrated about that. Ah, so in *this* case you're actually hijacking the *table* display while ignoring semantics. You could just use a table to display it (I think the semantics would probably be okay). If you want the list semantics specifically, use a *single* list and wrap each translation in a container that you can then give a defined width so that they stack next to each other. That's just the first thing that came to mind. The most attractive feature of HTML to me is that it does not say Resolution 800×600 required — indeed, there are products that require it without saying, which is even worse. I am worried such an explicit layout would make the text unreadable on lower resolution displays and hard to read on higher resolution displays. And moreover, merging the lists is breaking them because either uses a different numbering style because they are in different languages. Chris
Re: [whatwg] Video
Dnia 02-04-2008, Śr o godzinie 10:55 -0500, Robert J Crisler pisze: Why should the W3C choose not create a better situation than the current one (which is a mess for developers and a mess for users), while continuing to work on the ideal? With all due respect: the mission of the WWW Corporation is to create standards, not to create situations. Situations are usually created by large companies and sometimes by user communities. Chris
Re: [whatwg] INS and DEL in lists
Dnia 26-03-2008, Śr o godzinie 12:42 -0500, Tab Atkins Jr. pisze: I'm coming around to the opinion that dl, ul, and ol (and the new list elements in html5) should allow a larger set of elements as their direct children. I've been playing around with hn within ul or ol (with the intended semantics being that it's a header *for the list*), as it provides a nice tight binding that makes it easier to style and move around with CSS. I could also use section or div, of course, but my solution communicates exactly the semantics I want and nothing else. OTOH it breaks the context-free structure of the DTD: INS can have LI only if within a list. I am not sure it is DTD-able. (Yes, it would make a counterargument to my own wish :-b) Chris
Re: [whatwg] INS and DEL in lists
Another example of missing interleave in HTML is not to be able to interleave list items with table rows in order to provide numbering. These are independent sets of elements and they cannot play together. Sad. Chris Dnia 25-03-2008, Wt o godzinie 20:44 +0100, Keryx Web pisze: Some of you might have seen this, but accpording to the original author there was no response. His suggestions make sense to me. I've been there as well. Lars Gunther This is from Thomas Thomassen on WSG's list: I was working on some examples for the use of del and ins. http://www.thomthom.net/blog/2008/03/document-history-viewer-making-use-of-del-and-ins/ As I was working on this I wanted to mark up a list where items had been added and removed. That's when I realised that you can't wrap up li dt or dd in del or ins elements because ul, ol and dl only allows list items as their direct child. The del and ins then have to be wrapped inside the list item. ul liItem 1/li lidelItem 2/del/li liItem 3/li /ul When I hid the del using display: hidden; the list would render something like this: * Item 1 * * Item 3 Because I could wrap up the entire list item, the bullet point would still remain. To me it appears illogical to not wrap the del or ins around the list items when you add and remove items to the list. I'm guessing it's a case where every scenario wasn't accounted for when the specifications was written. (Yes, I know that I could add an extra class to the list item that I wanted to hide, but it's not the point. It shouldn't be necessary.) However, when this scenario presents itself I see it as fine to break the specification and mark it up like this: ul liItem 1/li delliItem 2/li/del liItem 3/li /ul This seem to render exactly as I expect it to do in every browser I've tested. * Item 1 * Item 3
Re: [whatwg] several messages about tables and related subjects
Dnia 23-03-2008, N o godzinie 19:29 +, Ian Hickson pisze:
Executive summary:
* header/id is in.
* summary= is not in.
* axis= is not in.
* the automatic header association algorithm has been expanded.
* a number of minor fixes and editorial edits were made.
For details, see revisions r1373 to r1396.
On Thu, 16 Aug 2007, Ben Boyle wrote:
Look at the balance sheet (3rd table). It's like we have nested sections
within the table. There's net assets that's broken down into current
assets, non-current assets and liabilities, each either their own
heading and totals (footer).
It would be interesting to investigate table markup that could support
complex relationships within tables like this. It may be a bit esoteric,
and can probably be handled through classes for those that need it. In
either case it's very important we can clearly associate the headers
with the right cells. I think it would be useful to be able to identity
the totals (footers?) in each section too.
For simple cases like:
WATER FOOD
CATS
male 871 12
female900 10
TOTALS FOR CATS1771 22
DOGS
male 871 12
female900 10
TOTALS FOR DOGS1771 22
TOTALS 3542 44
...you can now easily get this effect by putting everything in the left
hand column into ths, everything on the top row into ths, and
everything on the bottom row into its own tfoot.
Does that work?
You are trying to map a cube onto a plane here.
It will never work,
except for the simplest cases the reader can easily imagine.
More formally, your table has two independent attributes enumerated:
table(species of {cats, dogs, all}, sex of {male, female, total})
and two dependent numerical ones:
= (water, food)
and should have the following four columns:
species sex water food
An alternative would be to use tabs
to present slices of the cube for different animals
--- but it is out of scope here, I presume.
I'm going to through a crazy idea into the mix and suggest that
section, header and footer may be useful within data tables for
this very purpose.
I'm not clear on how that would work. (Especially considering backwards
compatibility and the CSS table model.)
Aren't the two answers below contradictory?
On Tue, 14 Nov 2006, Simon Pieters wrote:
Currently tbody requires at least one tr element. [1] Why not zero
or more? I think tr is for tbody like li is for ul/ol (or a
dtdd group is for dl).
Because if you have zero tr elements, you actually have zero tbody
elements, which is allowed.
On Thu, 5 Apr 2007, Simon Pieters wrote:
Why does tbody require one or more tr elements, as opposed to zero
or more?
Fixed.
Cheers,
Chris
Re: [whatwg] Superset encodings [Re: ISO-8859-* and the C1 control range]
Dnia 13-03-2008, Cz o godzinie 02:04 +0100, Øistein E. Andersen pisze: PPS: Some right-to-left characters contaminate surrounding characters as I have not yet found a simple solution to make everything strictly left-to-right (probably because I have not looked for it properly). Some characters, like digits, are direction-transparent, they inherit direction from the preceding text. Inserting an LTR mark before them makes them LTR. Chris
Re: [whatwg] HTML 5 - comments on 5.6 Command APIs
Dnia 11-03-2008, Wt o godzinie 19:31 +, Tom Gilder pisze:
On Tue, Mar 11, 2008 at 6:15 PM, Krzysztof Żelechowski
[EMAIL PROTECTED] wrote:
I see no point in returning true when there are no links to remove. IE
and Opera currently only return true when the selection contains a
link. WebKit follows the current HTML 5 wording.
Unlink means Remove all links.
There is no point removing all links when there are none
but there is no harm either.
Me thinks Unlink should be enabled in this case.
queryCommandEnabled is primarily, I would argue, used to update UIs
(especially enabling/disabling toolbar buttons) to show whether the
command will currently have any affect on the document.
There is indeed never any harm in calling execCommand('Unlink'), you
can call it as much as you like at any point without raising an
exception, but execCommandEnabled is surely about whether the call
will actually achieve anything.
Following your logic, queryCommandEnabled('Undo') could always return
true, because there's no harm in trying to undo even when there's
nothing to undo.
I have mixed feelings about this.
I admit there is no practical harm; however,
Undo means undo the latest action
and it is an error to say take your hat off
to somebody who does not wear one.
I resembles popping from an empty stack;
this action usually throws.
On the other hand,
it is not an error to say Give me all your money
to somebody who does not have any.
execCommandEnabled is pointless unless it actually returns a useful
value as to if it's going to do something.
I would read it more literally: it is enabled when it can be executed.
Your version should be called execCommandEffective.
Chris
Re: [whatwg] HTML 5 - comments on 5.6 Command APIs
Dnia 10-03-2008, Pn o godzinie 03:09 +, Tom Gilder pisze:
3) HTML 5 suggests queryCommandEnabled('Unlink') returns true with any
selection:
Enabled When: The document has a selection that is entirely within
an editing host.
-- http://www.whatwg.org/specs/web-apps/current-work/#unlink
I see no point in returning true when there are no links to remove. IE
and Opera currently only return true when the selection contains a
link. WebKit follows the current HTML 5 wording.
Unlink means Remove all links.
There is no point removing all links when there are none
but there is no harm either.
Me thinks Unlink should be enabled in this case.
Which of the following use cases do you consider more common?
Case 1: remove all links (if there are any)
Case 2:
remove all links, handle an exception if there are none?
Methinks, case 1 wins
Chris
Re: [whatwg] Canvas ath construction over save/restore boundaries
Dnia 07-03-2008, Pt o godzinie 04:16 -0800, Oliver Hunt pisze: Hi all, while working on a bug in our canvas implementation I've noticed that there's a difference in behaviour between Opera and Firefox when handling path construction over save/restore boundaries. Section 3.12.11.1.1 says that the canvas path is not part of the state that is effected by save/restore, unfortunately Opera and Firefox disagree on what this actually means. Firefox appears to treat restore() (effectively) as a transform that undoes the any transformations performed in the current state, so given the example: context.beginPath(); context.save() context.translate(100,100) context.rect(0,0,10,10) This instruction means to me: put a rectangle on a drawing plane, not over it. Once it has been put, it cannot be moved. context.restore() context.fill() Firefox behaves as though the set of operations was context.beginPath(); context.translate(100,100) context.rect(0,0,10,10) context.translate(-100,-100) context.fill() which, given 3.12.11.1.8., results in the fill operation still drawing a 10x10 rect at (100,100). Opera meanwhile treats the path as being completely independent of the canvas state, and so draws the rect at (0,0). Firefox is right. What I want to know is which behaviour the spec actually intends on providing. --Oliver
Re: [whatwg] Geolocation API Proposal
Dnia 05-03-2008, Śr o godzinie 23:36 -0800, Aaron Boodman pisze: Hi all, We're adding an API to Google Gears that will allow an application to obtain (with permission) the user's current location. Here's our current design: http://code.google.com/p/google-gears/wiki/LocationAPI We think there's a lot of potential for interesting applications with an API like this. Some examples would be recommendations for nearby restaurants, turn by turn directions, or city walking tours. What do people think of adding something like this to a future version of HTML? The intersection of this interface with HTML is empty and it will always be because it does not hook on anything to declare. It qualifies as a browser extension. IMHO, Chris
Re: [whatwg] Geolocation API Proposal
Dnia 06-03-2008, Cz o godzinie 08:30 -0800, Aaron Boodman pisze: On Thu, Mar 6, 2008 at 8:14 AM, Krzysztof Żelechowski [EMAIL PROTECTED] wrote: The intersection of this interface with HTML is empty and it will always be because it does not hook on anything to declare. It qualifies as a browser extension. How is it different than the HTML5 database API? A database is general-purpose and this is an oracle for answering one question. In any case, I wanted to post this here because this seems to be where the right people are. But if you think there's a more appropriate group to approach, let me know. How about defining a URI scheme to be used with XMLHttpRequest? Where the URI will be 'about:geolocation' (or 'about:whereami') and the result is text/xml (or text/gps+xml)? I think browser extensions can easily hook into the about scheme and intercept it. Chris
Re: [whatwg] Usemap and ismap for canvas tag
Dnia 05-03-2008, Śr o godzinie 09:39 -0600, Greg Houston pisze: On a side note, I was just glancing over the newly released, Internet Explorer8 Readiness Toolkit, and it says: Internet Explorer 8 offers Web developers the opportunity to write standards-compliant HTML-based Web pages that support features (such as SVG, XUL, and MathML) in namespaces, provided that the client has installed appropriate handlers for those namespaces via binary behaviors. (A binary behavior is a type of ActiveX control.) I am not entirely sure what that means, but it looks like users will still have to install something in order to view SVG with Internet Explorer. There is no mention of canvas. FYI: It means you use a custom tag instead of OBJECT; the control to embed is determined by the tag name and the binary behaviour provides the associations. It is more convenient when you intend to use several embedded elements or have the element data in-line. The main objection is that such a document is nonconforming. There are two ways to embed foreign content in HTML: the SCRIPT element and a data URI. SCRIPT has its limitations (no decrement operator in JavaScript) and data URIs are cumbersome and unsupported by IE. XHTML is somewhat more flexible but IE offers to save it to disk or displays it as a tree unless you cheat about the content type in which case you break everybody else. (You have to explicitly forbid ASP to cheat if you do not want it to because ASP think and instruct the developer that XHTML is just like HTML, only better.) Looks like a dead end to me. Keep smiling Chris
Re: [whatwg] HTMLDocument hasFocus - should it be a function?
Dnia 04-03-2008, Wt o godzinie 14:53 -0800, Adele Peterson pisze: I started implementing the hasFocus attribute in WebKit, but then I realized that IE and Firefox 3 both implement it as a function. Should the spec change to match the existing implementations? This property is so volatile that making it a function would be more intuitive. +1 Chris
Re: [whatwg] several messages about the HTML syntax
Dnia 03-03-2008, Pn o godzinie 20:18 +, David Gerard pisze: On 03/03/2008, Ian Hickson [EMAIL PROTECTED] wrote: On Mon, 3 Mar 2008, Krzysztof Żelechowski wrote: When I want to define a paragraph-style tool-tip, I am left with the following choice: either make the source code unreadable by making an excessively long line (this is also true for URI attributes but they are not expected to be readable) or make the tool-tip ugly by inserting line breaks. (It cannot be done in an portable way because the width of the tool-tip window and the fount metrics at the viewer's UI are unknown). I recommend not making paragraph-long tooltips. That's terrible user interface. But how will we read the asides on xkcd.com ?! Admittedly, we cannot, at least not in Firefox. Hm. Chris
Re: [whatwg] Proposal for a link attribute to replace a href
Dnia 28-02-2008, Cz o godzinie 19:51 +, Philip Taylor pisze: Are there cases where div ...a href=... style=display:block; width:100%; height:100% ... /a/div is not adequate for making block links? It does not make the anchor a block element, it is still a text element, although with block display. It cannot contain flow content. button type=submit link=javascript:event.preventDefault() The URI is semantically incorrect because event is undefined. Chris
Re: [whatwg] several messages about the HTML syntax
Dnia 02-03-2008, N o godzinie 23:02 +, Ian Hickson pisze: On Tue, 31 Jul 2007, Simon Pieters wrote: Aha. I didn't think of testing attributes. Safari preserves CRs in attribute values, both real and NCRs. CRLF pairs, LFCR pairs, CRs and LFs cause a single linebreak in the tooltip. In data, CRs don't cause linebreaks. For title=, IE preserves CRs in attribute values, both real and NCRs. CRLF pairs, CRs and LFs in the DOM gets rendered as a signle linebreak in the tooltip. For value=, all types of linebreaks are converted to CRLF pairs. In data, only CRs cause linebreaks and LFs are rendered as spaces. Firefox preserves CRs in attribute values, both real and NCRs. CRs are ignored and LFs are rendered as spaces in the tooltip. In data, CRs don't cause linebreaks. For title=, Opera drops LFs in attribute values, both real and NCRs, and converts CRs (both real and NCRs) to spaces. For value=, CRs and LFs are preserved as written, both real and NCRs. Personally, I think attribute values should be parsed the same way as data is parsed wrt linebreaks. I agree. I oppose. When I want to define a paragraph-style tool-tip, I am left with the following choice: either make the source code unreadable by making an excessively long line (this is also true for URI attributes but they are not expected to be readable) or make the tool-tip ugly by inserting line breaks. (It cannot be done in an portable way because the width of the tool-tip window and the fount metrics at the viewer's UI are unknown). I recommend: convert line feeds to spaces, use #8232; and #8233; where appropriate, use #10;, #13; where necessary (these should not be converted to spaces). Chris
Re: [whatwg] The div element
Dnia 01-03-2008, So o godzinie 19:37 -0800, Nicholas C. Zakas pisze: Reading your description makes me think that you're more displeased with the hn/ elements than you are happy with the section/ element. I've never had issues promoting headers or moving content around, and I'm not clear that section/ would help in any of these circumstances. Nested sections using different hn/ elements seem more confusing to me than just using the hn/ elements. You can paste the section text without modification and the headings will get the correct level automatically. It is a good thing. Chris
Re: [whatwg] Thoughts on HTML 5
Dnia 01-03-2008, So o godzinie 19:36 -0800, Nicholas C. Zakas pisze: I understand your reasoning for the aside/ element, perhaps this is another element that is suffering from the wrong name. Most of web developers have no idea what an aside is let alone when to use one. I know that acronym/ was removed because it confused web developers. Given that this is the same audience, the ones who couldn't figure out the difference between an acronym and an abbreviation, do you really think that aside/ will get used? Perhaps it would better be named callout/? Aside is customary in dialogue annotations, I have never seen any callout. Chris
Re: [whatwg] Issues concerning the base element and xml:base
Dnia 01-03-2008, So o godzinie 17:12 -0800, Maciej Stachowiak pisze: On Mar 1, 2008, at 4:20 PM, Jonas Sicking wrote: For example on a a href=..., does the user hovering the node count? If you display an absolute URI to the user at this time it should get resolved against the current base, but since this is not a load, it should get resolved again when the user clicks the link, if the base changed. I am not sure I understand you correctly but if this introduces the ability to make the user agent report a different URL than the effective target, it is going to be a sweet candy for phishers. (Newer browsers made this effect unavailable to scripts). Chris
Re: [whatwg] several messages about handling encodings in HTML
Dnia 29-02-2008, Pt o godzinie 01:21 +, Ian Hickson pisze: In 8.2.2.4, I have no idea what's the reason or purpose of point 1, which reads If the new encoding is UTF-16, change it to UTF-8.. I suspect some misunderstanding. This is required because many pages are labelled as UTF-16 but actually use UTF-8. For example: http://www.zingermans.com UTF‒16 cannot be transmitted over Internet anyway so it must be changed to something because what comes in is certainly not UTF‒16-encoded. This declaration is in error; one of the possible universal encodings UTF‒8, UTF‒16LE and UTF‒16BE should be chosen that produces valid markup for the decoded document. Chris
Re: [whatwg] several messages about figure and related subjects
Dnia 27-02-2008, Śr o godzinie 08:06 -0500, Michel Fortin pisze: Now, suppose you have this: pA header looks like this in your browser:/p h1Some text!/h1 ... unfortunately, the h1 here isn't a real header in the document: it's an illustration of a header (ah-ha: figure!) which can't be removed from te flow of the document (oops, can't use figure). There's no rational way to markup this with the current wording of the spec; abusing figure is the most reasonable option I can find: pA header looks like this in your browser:/p figureh1Some text!/h1/figure The problem being that figure needs the ability to be moved around without changing the meaning of the document, so the markup above would be non-conforming because the sentence just makes no sense if you put the figure elsewhere. Perhaps figure could have an optional anchored attribute to indicate it belongs to a specific point in the document. If the page has a header, you can refer the reader to its ordinary header instead. The purpose of headers is to make looking around the page easier; your sample header would be a distraction if it is styled like a normal header and would not make a good demonstration if it is not. Chris
Re: [whatwg] Proposal for a link attribute to replace a href
Dnia 28-02-2008, Cz o godzinie 23:18 +1100, Shannon pisze: Markus Ernst wrote: Anyway, why do you suggest a new attribute rather than making the existing href attribute global? Because I think some current and depreciated tags still use href for a different purpose (base for one). A global attribute should be unique. I don't really mind what the attribute is called. BASE is invisible so it does not matter. Chris
Re: [whatwg] Proposal for a link attribute to replace a href
Dnia 27-02-2008, Śr o godzinie 23:25 +1100, Shannon pisze: ---LINK with block-level or interactive content--- This proposal would circumvent A's main limitation which is its requirement to not wrap block-level elements or 'interactive' content. The HTML5 draft requires it wrap 'phrasing content' (essentially paragraphs) and not wrap 'interactive' content (such as other hyperlinks) however I see no reason why a link attribute should require these limits. Links would simply cascade as in the following example: table link=alphabet.html title=Alphabetical List tr tdA/td tdB/td td link=c.html title=More about CC/td tdD/td /tr /table Tables should be used to present tabular data. Tabular data is something the user may want to meditate or to copy; their content cannot be grasped in a glance. Hyperlinked text should be a concise description of the content of the other page; a table does not meet that requirement. This design violates the least surprise principle. In the example above clicking anywhere on the table except 'C' brings up a generic page, whereas 'C' has dedicated content. The following nested links would also be valid: span link=foo.htmlclick anywhere on this line except b link=bar.html title=Go to bar insteadhere/b to visit foo./span It would be difficult to style a hyperlink within a hyperlink; moreover, a hyperlink that contains another hyperlink is not concise, see above. Chris
Re: [whatwg] cite, q cite=, and blockquote cite=
Dnia 20-02-2008, Śr o godzinie 06:36 +, Ian Hickson pisze: I've added a note to myself to make it clear that cite= should be made available, e.g. on hover. E.g. in the context menu as Go to original (should be Go to source but that would be too ambiguous ☹). I really detest the practise of showing automatic windows with active elements on hover. It hides interesting content and it is too intrusive. Chris
Re: [whatwg] Canvas patterns, and miscellaneous other things
Dnia 31-01-2008, Cz o godzinie 02:02 +, Ian Hickson pisze:
On Sat, 23 Jun 2007, Philip Taylor wrote:
Similarly, what should toDataURL do when the canvas is really large and
the browser doesn't want to give you a data URI? (Opera returns
'undefined' if it's = 30001 pixels in any dimension, and crashes if
it's 3 in each dimension. Firefox (2 and trunk) crashes or hangs on
Linux if it's = 32768 pixels in any dimension, and crashes on Windows
if it's = 65536 pixels).
User agents may impose implementation-specific limits on otherwise
unconstrained inputs, e.g. to prevent denial of service attacks, to guard
against running out of memory, or to work around platform-specific
limitations. (See ...#hardwareLimitations.)
Although the right way of returning in this case
is throwing an exception, as noted below.
More generally, the spec says If the user agent does not support the
requested type, it must return the image using the PNG format - what if
it does support the requested type, but still doesn't want to give you a
data URI, e.g. because it's the wrong size (too large, too small, not a
multiple of 4, etc) or because of other environmental factors (e.g. it
wants you to do getContext('vendor-2d').enableVectorCapture() before
toDataURL('image/svg+xml'))? (Presumably it would be some combination of
falling back to PNG (if you asked for something else), returning
undefined, and throwing exceptions.)
The spec doesn't define support the requested type. I could definitely
see arguing that support of the requested type is dependent upon other
factors, so that returning a PNG is ok. Throwing exceptions in the face of
hardware limitations (data too big) is always allowed, as noted above.
Also, browsers could crop or extend or stretch the image if the image
format requires a particular multiple in its output dimensions. That's
just part of outputting the image.
Re: [whatwg] accesskey
Dnia 25-01-2008, Pt o godzinie 23:06 -0500, Jean-Nicolas Boulay Desjardins pisze: In the present standard you are alowd to use the same accesskey in to different links... For example: a href=bob.html accesskey=bBob web page/a a href=bob.html accesskey=bBob web page/a But what would happend if this was to happend: a href=bob.html accesskey=bBob web page/a a href=alex.html accesskey=bAlex web page/a Again this is allowed in the present web standard, but if you think about it its illogical, on what bases thus the browser decide wich one to access first or should it open the tow? The visible and enabled elements marked with the same access key should take focus in turn and in page order. If the element is an active element, its action should not be performed. Chris
Re: [whatwg] More random comments on the putImageData definition
Dnia 25-01-2008, Pt o godzinie 15:05 -0800, Oliver Hunt pisze: Ah true I had forgotten that, however this still fails for non- integral ratios :-/ Non-integral ratios can be approximated by a series of rational ones. Chris
Re: [whatwg] nextSiblingElement ?
Dnia 23-01-2008, Śr o godzinie 22:50 -0800, Garrett Smith pisze: nextSibling and previousSibling are useful, but not always what I want. nextSibling is all right if you replace UL LI /UL with UL LI /UL . It may look funny at first and WYSIWYG editors know nothing about that but otherwise it works all right and you can get used to it (it is the best solution for me). Chris
Re: [whatwg] How to use SVG in HTML5?
Dnia 24-01-2008, Cz o godzinie 08:50 -0500, Vlad Alexander (xhtml.com) pisze: Embedding SVG by reference (thought the img element) is well suited to HTML. SVG was designed for this as stated in Embedding by reference section here: http://www.w3.org/TR/SVG11/concepts.html#UsageOptions This is a permission from SVG's side: the designer of SVG permits HTML content to use IMG for SVG if HTML allows it. It should not be viewed as an obligation imposed upon HTML though. I tested Opera's support for SVG through the img element and it incorrectly clips the SVG image. The width and height attributes of the img element need to set the viewport for the SVG image and scale the SVG non-uniformly to fit the viewport. The advantages of using the img element to render SVG over the object element or inline SVG are: 1. Existing authoring tools and CMS can support SVG without major modifications. For example, most CMS that support image libraries are hard wired to generate the img element when an image is selected from an image library. They are all wrong (non-compliant). There are two ways to embed an image for all those Internet Explorer users to view: 1. Ask QuickTime to display the image as an object (first time requires administrator privileges) 2. Make it a background image of a suitably sized empty container. It is somewhat hard to make the container be displayed in-line but images for the sake of themselves rarely need such display. As a side effect, the right click download is disabled, which is something many publishers are after. 2. Using SVG through the img element is more accessible solution because existing assistive technologies support the alt attribute whereas support for the object fallback mechanism is limited Limited to what? and support for inline SVG is non-existent. And rightfully so. Also, even though SVG supports title and desc elements which are meant to increase accessibility of SVG, most SVG documents do not use them. So having the alt attribute on the img element is more accessible solution than relying on title and desc inside SVG. I parrot: Most HTML documents do not have it or have some nonsense in it. Which of course is no more an argument than yours, i.e. nil. Regards, Chris
Re: [whatwg] How to use SVG in HTML5?
Dnia 23-01-2008, Śr o godzinie 14:44 -0500, Sam Ruby pisze: On Jan 23, 2008 2:13 PM, Krzysztof Żelechowski [EMAIL PROTECTED] wrote: SVG is too heavyweight for the purpose of such tiny presentational enhancements. I can provide counterexamples: http://intertwingly.net/blog/ http://intertwingly.net/blog/archives/ - Sam Ruby All right, I hereby grant you the right to use in-line SVG provided the only element used inside is solid filled path. (No gradients, transformations, mitres, text and such). I remember using VML in this spirit myself. Thanks for the redirection, the pictures are very nice! Chris
Re: [whatwg] How to use SVG in HTML5?
Dnia 24-01-2008, Cz o godzinie 07:34 +1100, Charles McCathieNevile pisze: On Thu, 24 Jan 2008 06:44:59 +1100, Sam Ruby [EMAIL PROTECTED] wrote: On Jan 23, 2008 2:13 PM, Krzysztof Żelechowski [EMAIL PROTECTED] wrote: SVG is too heavyweight for the purpose of such tiny presentational enhancements. I can provide counterexamples: http://intertwingly.net/blog/ http://intertwingly.net/blog/archives/ An image is not a replacement for text in the real world, only in Ian's current drafts. Ian never said say that about images in general but about image elements. And your reply is not related to the examples: they do NOT use IMG (correct). Chris
Re: [whatwg] Reverse ordered lists
Dnia 23-01-2008, Śr o godzinie 17:28 +, James Graham pisze: The problem that Jonas originally pointed out is that, given browsers do incremental rendering number of items is not a known quantity when the list is first rendered. For a pathological example of why this is a problem, imagine a cgi script that just kept spewing out reverse numbered list items, one per second, indefinitely. This is not specific to lists; any content without incremental rendering capability would cause this effect. Chris
Re: [whatwg] How to use SVG in HTML5?
Dnia 23-01-2008, Śr o godzinie 13:42 +, David Gerard pisze: Forgive me if this is a simple and obvious question. I note that all current browsers (except IE, of course) implement SVG rendering (to a better or worse degree). I'd like to be able to drop SVG images into an HTML page as easily as I can a JPEG or PNG. I read over the recently-released HTML5 draft and couldn't work out how I'd do this. What would the HTML to do this look like? What's the equivalent of IMG SRC=foo.jpg for foo.svg? There is none, and there should not be. An IMG element is a replacement for inline text that can be rendered at the viewer's option, an SVG element is an embedded object of its own. SVG is too heavyweight for the purpose of such tiny presentational enhancements. Chris
Re: [whatwg] Reverse ordered lists
Dnia 23-01-2008, Śr o godzinie 15:15 +0100, Dave Singer pisze:
At 15:03 +0100 23/01/08, Lachlan Hunt wrote:
Simon Pieters wrote:
ol start=100 reverse
The lack of start='' would make the numbers update as the list is
filled with lis. This allows both for simplicitly for short lists
and correct incremental rendering for large lists.
No, the lack of an explicit start attribute would make it start from
the default value: 1. It would then count down from there:
1. A
0. B
-1. C
-2. D
which suggests a pair of orthogonal attributes, as above, the
direction ('order'='increasing' or 'decreasing'??) and the initial
ordinal value (which should be a number, even if the styling asks for
e.g. alphabetic labelling).
perhaps
(from a non-expert)
Ordinal numbers should never be negative; they should always have an
alternative representation using letters (spreadsheet-style).
Negative numbers were first justified because they turned out to be
essential for solving cubic equations; anything less sophisticated can
do without them.
If the start value is too small and the ordinal number descends below 0,
the user agent should leave the remaining items unmarked.
The page will be ill-formed;
the author is obliged to provide a valid value for the start attribute.
The reverse attribute without a tentatively valid start attribute
should be ignored.
Chris
Re: [whatwg] How to use SVG in HTML5?
Dnia 23-01-2008, Śr o godzinie 20:42 +, David Gerard pisze: FWIW, my use case is to be able to create images in SVG and just use them as ... images, just like I do PNGs or JPEGs. It was also somewhat inspired by setting up rsvg for MediaWiki on our work intranet and wanting to hit it repeatedly with a hammer ... but relying on client-side SVG rendering will have to wait until Firefox 3 renders it not only correctly, but without pegging the processor just displaying ;-) I think Chris is incorrect in his assertion because clients can be presumed to have increasing amounts of rendering power available just to make pretty pictures. That does not necessarily mean that the owner of the rendering device would be happy to watch the user agent use that power for something inessential (battery life!). Besides, your paragraph 2 directly contradicts paragraph 1: the implementations are not mature. Every browser (except IE) *has* SVG rendering. And that means that, optimistically, one user in three will have a chance of viewing the content as you intended (unless your target audience is very specific). Firefox 3 will have *accurate* SVG rendering. SVG is the Right Thing for so many situations. It's all looking promising to me so far. While it is nice and comforting to have a promise, it is wise not to rely on it too much. Chris
Re: [whatwg] Reverse ordered lists
Dnia 23-01-2008, Śr o godzinie 15:34 -0600, Siemova pisze: If you mean that a script should be able to use that automatically-generated value, I'm sure that's true, but there are cases wherein the content creator doesn't have access to the script in order to build that in. For example, the very case which inspired me to propose this feature involved a list of items generated in reverse order by a CMS. A CMS is a smart engine, it is not limited to composing content from various sources; it is possible (and probably necessary) to do various fix-ups anyway before sending to the user agent. Chris
Re: [whatwg] Canvas ImageData comments
Dnia 18-01-2008, Pt o godzinie 13:19 +, Philip Taylor pisze: Oops, I was wrong to mention that - 'different than' seems to be common in some Englishes, and I don't want to complain when it's just dialect variations. To me, different from is closer to dissimilar and corresponds to the question What are the difference between… whereas different than is closer to unequal. In other words, a swan is different from a goose but the height of Mount Everest is different than the height of Mont Blanc. (Note, however, that 0 is different from 3: adding 0 does not change the result, etc.)
Re: [whatwg] Canvas operators (was Re: several messages)
Dnia 16-01-2008, Śr o godzinie 02:48 +, Ian Hickson pisze: On Sun, 20 May 2007, ddailey wrote: Another question arises in my mind in this context: is there any reason that any of the treatments of these effects (like the Porter-Duff operators, darken, saturate etc.) should be any different than they are in the SVG spec? So many things that I see in the treatment of canvas remind me of something so similar to what is in SVG that it makes me wonder why not just reference say http://www.w3.org/TR/SVG/filters.html ? The canvas globalCompositeOperation is just defined in terms of PorterDuff, which far predates SVG. And why does the canvas specification have to pretend that it predates SVG too? Chris
Re: [whatwg] must only ambiguity
Dnia 24-12-2007, Pn o godzinie 16:36 -0500, L. David Baron pisze: On Monday 2007-12-24 19:07 +0100, Krzysztof Żelechowski wrote: My rewording for competition: Authors may use elements in the HTML namespace in the contexts where they are explicitly allowed and nowhere else. My rewording for competition: Authors may put elements inside an element only if that element... (because only if is a common and well understood expression.) These won't work because they make the statement a much weaker requirement per RFC 2119: http://www.ietf.org/rfc/rfc2119.txt Changing from a MUST or MUST NOT to a MAY is a substantive change, not a rewording. RFC 2119 does not forbid using MAY conditionally. Under these conditions, this is a MAY, otherwise this is a MUST-NOT. If you prefer MUST NOT to MAY NOT, which is about the same in English, you can say ... and MUST NOT use them anywhere else. Note that this is a true MAY, not a MUST; you NEED NOT use any HTML elements at all, except for a few that make the basic skeleton of a document, and I may even be wrong here because those elements may be supplied by the user agent so that an empty document is a valid document; but that MUST is described elsewhere, and I may even be wrong here because those elements may be supplied by the user agent so that an empty document can be treated as valid. Chris
Re: [whatwg] Possible alternative to specifying a codec for the video tag
Dnia 23-12-2007, N o godzinie 13:08 +, David Gerard pisze: On 23/12/2007, Robert (Jamie) Munro [EMAIL PROTECTED] wrote: How could we do that? The codec is usually a relatively small download download compared to the video itself. If we could suggest a way for codecs to be provided alongside the videos by the content providers, this /may/ be a way forward. Hypothetically, you could do video by adding better binary file handling to Javascript, and painting on the canvas, but good performance is unlikely. Arbitrary executable downloads didn't work out well with ActiveX, and Download codec to view this! is already a vector for malware. That would not be an arbitrary download; it would be a download of _the_ codec. The executable code must not be enclosed in the content envelope (unless the envelope is generated on the fly by the server depending on the user agent; I think it would be a cumbersome thing to do). Arbitrary active extensions can request services from the operating system; the code to be executed should not be allowed to. It could be allowed to request services from the browser only; if that is set up correctly, the decoder will be as safe as the browser is, even if it is a piece of broken malware. Thus we would need the browser to be a direct show* engine provider for the decoder and the decoder would be allowed to access its own memory only and call its own functions and the functions explicitly provided by the browser. Is this feasible? Who would be in charge of wrapping the decoder for all the various browser implementations out there? Because each of them can provide a different interface to the decoder. The publishers? And what if some browser vendor decides to issue an incompatible update? I doubt the publishers are able to follow the technology that closely; they probably have something else to do. The decoder engine vendors? They should be able to this but their consent, or at least their opinion, is required in this case. And, last but not least: can we expect the opposing browser vendors to offer the direct show engine and allow the decoder to run without much user intervention? Because if not, this solution would be very weak. What do you think? Chris *(Note: DirectShow, IIRC, is a video-related trademark owned by Microsoft. I used it here because of lack of a better expression.)
Re: [whatwg] must only ambiguity
Dnia 21-12-2007, Pt o godzinie 17:28 +, Philip Taylor pisze:
Documents and document fragments / Structure says Authors must only
use elements in the HTML namespace in the contexts where they are
allowed, as defined for each element.
That phrase is unclear. It could be interpreted as:
Authors must { only use elements in the HTML namespace } in { the
contexts where [elements in the HTML namespace] are allowed }, i.e.
contexts expecting HTML namespaced elements mustn't contain foreign
content.
Authors must { [...] use elements in the HTML namespace } [only] { in
the contexts where they are allowed }, i.e. HTML elements must not be
used where they aren't allowed.
Authors must only { use elements in the HTML namespace in the
contexts where they are allowed }, i.e. pretty much every imaginable
action in the entire world is disallowed, except for using elements
where allowed.
A suggested replacement: Authors must not use elements in the HTML
namespace except where allowed by the context defined for the
element.
My rewording for competition:
Authors may use elements in the HTML namespace
in the contexts where they are explicitly allowed and nowhere else.
Similarly, Authors must only put elements inside an element if that
element allows them to be there according to its content model should
be fixed to say something like Authors must not put elements inside
an element unless that element allows them to be there according to
its content model.
My rewording for competition:
Authors may put elements inside an element only if that element...
(because only if is a common and well understood expression.)
Chris
Re: [whatwg] +/- in SGML DOCTYPE
[83.1] N/A because W3C is not an IDN. Dnia 16-12-2007, N o godzinie 00:49 +0100, Terje Bless pisze: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] (Geoffrey Sneddon) wrote: ISO 8879:1989 states that SGML public text owner identifier registration (i.e., those that start with a + instead of the unregistered -) is defined in ISO 9070, which I don't have a copy of. I can, however, quote the summary from ISO 8879:1989: These [registered owner identifiers] include standards body identifiers for national or industry standards organisations (similar to the ISO owner identifier), and unique codes that may have been assigned to organisations by other standards. Annex K (“Web SGML Adaptations”) to ISO 8879 TC2: [[[ K.4.6 Internet domain names in public identifiers [80] owner identifier = ISO owner identifier | registered owner identifier | unregistered owner identifier | internet domain name owner identifier [83.1] internet domain name owner identifier = +//IDN , minimum data where the minimum data must begin with an Internet domain name.
Re: [whatwg] HTML5 and URI Templates
Dnia 15-12-2007, So o godzinie 19:28 -0800, James M Snell pisze:
form template=http://example.org{-prefix|/|foo}?bar={bar}
method=POST
Foo: input name=foo type=input
Bar: input name=bar type=input
/form
Why is this prefix operator needed here?
What is wrong with the URL http://example.org/?bar=input?
Chris
Re: [whatwg] The truth about Nokias claims
Dnia 15-12-2007, So o godzinie 11:41 +0100, Maik Merten pisze: Krzysztof Żelechowski schrieb: Dnia 14-12-2007, Pt o godzinie 19:47 +0100, Maik Merten pisze: Krzysztof Żelechowski schrieb: Remember the - in DOCTYPE HTML? Feel free to be more specific. That prefix means that HTML DOCTYPE is not issued by an officially recognised standards body. If W3C were such an organisation, we would have a + there instead. And does that matter in any way in practice? More freedom for the consortium, I think, and less influence. For example, a law is more likely to refer to an ANSI standard. The W3C is the de-facto sole maintainer of many technologies the web depends on. People love to use the term web standards in conjunction with W3C recommendations. It is all right to be imprecise sometimes. Chris
Re: [whatwg] The truth about Nokias claims
Dnia 15-12-2007, So o godzinie 21:14 +1100, Shannon pisze: They are not easy ways forward, I agree. How would _you_ recommend addressing Apple's requirements while still addressing the requirements of the rest of the community? I would recommend that Apple and Nokia follow the example set by Goomplayer (and others) by allowing users to download codecs on-demand from third-party providers (like Sourceforge). If I were Apple, I would not want my product to be contaminated by rogue code and zombified. In case that happens, I would be held guilty, not the contaminator. This puts the risk squarely in the users court and better yet allows Safari/Quicktime to adapt to new codecs in the future. It may be my foggy memory but last I checked Quicktime could already do this. If such a time comes that the patent risk is resolved they could bundle it then. However, most media players are bloated enough without bundling every codec so it's really a win for everybody. If this still wasn't enough then they could join a patent pact with other large vendors to provide a mutual defense / shared liability fund. If Ogg was under threat they'd probably get the FFII to help them fight it pro-bono. Please observe that nobody asked you what you think Apple should do. Chris
Re: [whatwg] The truth about Nokias claims
Dnia 14-12-2007, Pt o godzinie 22:06 -0800, Joseph Daniel Zukiger pisze: Has someone made the precise suggestion I made? Specifically: (1) Require (MUST) a container/codec not known to be encumbered for the video tag. (2) Require an open plugin API for the browser, so that 3rd-party implementations can be dropped in, and allow the requirement of (1) to be met by a third party plugin. (3) Mention Ogg as an example of container/codecs which are not presently known to be encumbered. I guess I can see a problem with that if it turns out that someone can make ogg appear to be encumbered. So it would probably need (4) Allow the requirement of (1) to be waived, or commuted to the next best thing available under RAND terms in the event that there are no implementations not known to be encumbered. The codec required must be specified explicitly by name, otherwise the online world will go apart. The statements above do not make a good solution because they are not precise enough. PS: (5) Take this issue to the US Congress to explain how strong IP laws actually do interfere with innovation by anyone but 800 ton^H^H^H pound gorillas. Do you think we have a representative among us? Besides, I think they are smart enough to know that. It does not help much because they are encumbered themselves. Make a donation to nosoftwarepatents.org and stop bringing it up here. Chris
Re: [whatwg] The political and legal status of WHATWG
Dnia 15-12-2007, So o godzinie 14:24 +1100, Shannon pisze: Ian, thank you for your answers re: video codecs. I agree with you now that everything that needs to said has been said regarding the change itself and I think most parties have made it clear how they feel and what they hope will resolve it. It's clear the opinions of all parties cannot be reconciled. The current text has not reconciled the views, nor did the previous, nor can a future one. It doesn't take a genius to figure out that this will not end well. I am quite certain the issue at stake here cannot be solved at the technical or legal level at all. This is truly a political/financial matter. Which brings us to the hard questions at the crux of the matter: 1.) When a browser vendor acts clearly outside of the public interest in the making of a public standard should that vendors desires still be considered relevant to the specification? Yes. 2.) When an issue is divided between a vendor (or group of) and 'the public' (or part of), what relative weight can be assigned to each? Zarro. The decisions should be based on consideration, not on voting. 3.) When a vendor makes false or misleading statements to guide an outcome should there be a form of 'censure' that does not involve a public flame war? False statements and misleading statements are subject to criminal penalties and civil litigation. 4.) If the purpose of the group is to build interoperability should a vendor be 'censured' for holding interoperability to ransom without sufficient technical or legal grounds? No. The group should invent a way out. 5.) What methods exists to define a disruptive member and remove them from further consideration? I assume that there should be some policy everyone has to accept before joining the group. 6.) Should a standards body make a ruling even though some members claim they won't obey it? It depends on the ruling. 7.) Should a standards body bow to entrenched interests to keep the peace? No. Thou shalt not bow except to thy Lawd. 8.) Does the WHATWG consider itself to be a formal standards body? I am not in position to answer that question but I would be surprised if it did. 9.) Should HTML5 be put back under direct control of the w3c now that they have expressed interest in developing it? Yes. 10.) Is is appropriate for members to have discussions outside of this list, via IM, IRC or physical means not available or practical to the public? Yes. 11.) Does the group consider HTML5 to be a 'public standard' or a 'gentlemen's agreement' between vendors? Actually, a public specification. 12.) Is it even legal for the majority of commercial browsers to form any agreement that could (directly or indirectly) result in higher costs for end-users? How do you prevent a 'working group' from becoming a cartel? Yes, it is. Only a government can prevent a formation of a cartel and only a court can dismantle one. These are not questions that anybody can easily answer. Some have probably been answered in this list but not, at least to my reading of it, in the charter, the wiki or the FAQ (none appear legally binding in any case). It is possible the lack of clear answers in an obvious place may threaten the impartiality and purpose of this group, damage your public image and inflame debate. I believe the reason for much of the 'heat' over the video codec is due to all parties (including non-members) coming up with their own answers in the absence of a formal position. That and a lot of mistrust regarding members corporate priorities. It is very good that all parties try to present their answers. That is what the group is for. I've read the charter but it doesn't define many rules. The w3c has rules but my understanding is that WHATWG is not a formal part of w3c (even if some members are). Public acceptance of the standard may not, in practical terms, be as important as vendor acceptance (to vendors at least) but since the public is, in many ways, doing much of the vendors work for them it would beneficial to have a clearer statement of how these contributions are weighed. To cite a theoretical example: if some altruistic billionaire was to write the 'missing codec' that exceeded h.264 in compression, used 64k of ram, ran on a 386 using 50 lines of code and he The number of lines of code is irrelevant here. or she paid off all the trolls and indemnified vendors - what actions, if any, would WHATWG members take to ensure it was accepted by members with vested interests? That is, by themselves? There is hardly any need to answer that, it is their business, not ours. If that last theoretical question cannot be answered then what hope have we for a baseline video format? We hope that the issue will be resolved in due course. Chris
Re: [whatwg] Acronyms Abbreviations whatwg Digest, Vol 33, Issue 90
Dnia 14-12-2007, Pt o godzinie 16:20 +0900, Karl Dubost pisze: Not to say that it creates localization troubles. For exactly the same meaning: TV in English = télé in French acronym abbr And what is supposed to do an automatic translator when translating something from English to Chinese for example. Drop the markup for acronym in some cases? Example English abbr title=telephoneTel./abbr: +86-10-8498-5588 Chinese 电话: +86-10-8498-5588 Clearly, an automatic translator is a very sophisticated piece of software. It has much more complicated tasks to do than just that. We can reasonably expect the translator to handle this case correctly as well. Best regards, Chris
Re: [whatwg] The truth about Nokias claims
Dnia 13-12-2007, Cz o godzinie 22:04 +0100, Maik Merten pisze: I think it all depends on definition and interpretation. If MPEG is an organization issuing real standards and Xiph is not... can e.g. WHATWG be considered to be issuing a real standard? Can individual companies issue standards? Is there a standard for creating standards? Remember the - in DOCTYPE HTML?
Re: [whatwg] The truth about Nokias claims
Dnia 14-12-2007, Pt o godzinie 06:58 -0800, Joseph Daniel Zukiger pisze: Just wait 'til the behemoth in Redmond has a loosely held independent subsidiary of something not visibly connected start making noises about how open source software might be encumbered. You can distribute source software that is encumbered, and sometimes you are required to open your source by the customer, in particular when the government is the customer. It is all right as long as you pay the licence fee. I believe many of the points being made in the most recent e-mails on this subject are points that have already been made many times. As far as I can tell, there are no satisfactory codecs today. As several keep trying to point out, there can be no satisfactory codecs, except satisfactory to certain parties, because, we have to assume for lack of other evidence, of backroom deals. As several keep trying to point out, you cannot push a codec of your liking down anyone's throat; in this sense, yes, there will be no a priori satisfactory codecs until the Congress starts preferring prudence to profit, which is not to expect soon IMHO. But there may be codecs that are satisfactory a posteriori.
Re: [whatwg] The truth about Nokias claims
Dnia 14-12-2007, Pt o godzinie 23:03 +1100, Shannon pisze: Again, a false presumption. This was discussed in the context of the HTML WG at the W3C. Those doors are not closed. Really? Does that mean I can claim a seat on the board? Where is this discussion about a public standard made public if not here? Please provide a link to these open discussions and I'll concede your point (and join - it is public, and free right?) That metaphor meant the doors are not closed for OGG to come back. I am not a member of the WWW Consortium but the information how to join is publicly available. I would not expect you can join free though; the membership gives you rights and imposes duties as usual. Look, I didn't request the change. I was OK with leaving a placeholder 'should' while we worked on a 'must'. Nokia preferred that the spec. indicated truthfully that work was continuing. This is hardly earth-shattering. I'm glad you didn't (and I never claimed you did) but the fact remains that Nokia did. Nokia requested, Nokia got, and you are defending them. When did you change your mind? I (and many others) make a reasonable request and get stonewalled. I'd like to think we are working towards the same goal and that we have different ways of doing it. Still, you have yet to reveal the magic codec that will make this go away. And yes, corporate self-interest is not earth-shattering, or relevant to a public specification when workarounds exist. You lost me. I see no 'holding to ransom', 'caving in', or anything. Then you haven't been reading Ian's previous posts. I am certain the subtext of his previous remarks was that HTML5 will stall if we didn't remove the OGG recommendation. I'm certain he mentioned 'major companies' being the reason for the change. Surely saying you won't adopt a standard because you disagree with an optional part is more disruptive than my questions? Besides, I really think you are too clever to misunderstand my claim. So what? HTML is a public standard, and at some point we will be asked to vote on it. We don't need a vote on this issue, now. We need work done. We don't need flames, either. I ask for the text to be reverted based on what appears to be public opinion and common sense. An educated opinion based on a lifetimes work. My questions are inflammatory only because the reason for asking them is. I believe the OGG recommendation IS the way forward and I believe I speak for others as well as myself. I have never made this personal or 'flaming' other than to question a poor decision by a minority interest. I am not using analogies about family members to make my points. My arguments, as always are logical and supportive of unencumbered standards. I don't think the current draft helps that and I don't think a better option than OGG is on the table (including saying that). I'm sorry this ended up on /. but again I had nothing to do with it - or the misinformation about OGG. If I wanted a flamewar I'd go to the Starcraft forums. This is serious and I am acting as calm as can be expected. Also I am a programmer. I have no objection in doing WORK to bring OGG up to a standard Nokia would accept - however let's be clear here - they wouldn't accept it anyway because they want H.264. The process does not need programmers but lawyers, unless you are ready to lock yourself in a conclave to build everything from scratch --- but you would have little chance of succeeding then. Then I am clearly wasting my time. Your understanding, approach and attitude all leave a great deal to be desired. Oh please. I understand Apple has a lot at stake in the video format wars. If you are wasting your time then I suppose that depends on why you are here. I have never lied about my motivation for requesting the draft to be reverted. MPEG-LA has said *absolutely nothing*. No they wouldn't. Fortunately I can read between the lines. Nokia is their frontman. Ask Nokia; they asked for the text to reflect reality. You prefer it reflect a false conclusion. *There is NO CONCLUSION YET*. You seem quite unable to grasp this simple fact. I am asking FOR a suggestion in the text to promote a public benefit. One that was there before Nokia's self-serving complaint. 'Reality' is currently 'defacto' standards. defacto standards that benefit a small group of companies. This is a standards organisation designed to prevent that. I'm asking this organization to take a stand. That is the way forward. Not quite. The principal goal of the organisation is to make online content easily available to everybody; benefits and losses can only be a side effect. Wonderful. I wish your understanding matched your altruism. It does. Again you insult my intelligence, while accusing me of 'flaming'. What is to misunderstand? The more poignant
Re: [whatwg] Asynchronous database API feedback
Dnia 11-12-2007, Wt o godzinie 11:22 -0800, Aaron Boodman pisze:
With an asynchronous API, it gets quite a bit messier. Here's an
example of what it might look like:
var messages = incoming_data;
db.transaction(function(tx) {
processNextMessage(tx);
});
function processNextMessage(tx) {
if (!messages.length) return;
tx.executeSql(insert into messages (id, subject, body) values (?, ?, ?), [
}
Please, it is only a matter of programming style. You can get used to
it, really. I actually prefer the code above to a synchronous one.
Chris
Re: [whatwg] whatwg Digest, Vol 33, Issue 90
Dnia 12-12-2007, Śr o godzinie 08:59 +, Ian Hickson pisze: Most people don't mark up abbreviations or acronyms at all, they only mark them up at all to give the expansions generally. And for this purpose, it doesn't really matter which is which (not to mention that different people disagree on which is which -- I say ess quere ell and ewe are ell, others say sequel and earl). SQL and URL are acronyms because they are built from initial letters. Mr., Dr., Ch. and cf. are abbreviations. i.e. and etc. are... er... abbreviations? Except for these cases, I hardly see any valid disagreement. A rule of thumb is that abbreviations are usually written with a dot. Chris
Re: [whatwg] Proposal for New Tag for UI Elements
Dnia 12-12-2007, Śr o godzinie 14:44 +0100, Thomas Broyer pisze: Only kbd inside kbd would be boxed then, so the + sign is not a problem: In this case you have to say KBD twice in simple cases, which is unacceptable because it is unexpected and it is going to be overlooked/ignored by the authors. pTo make George eat an apple, press kbdkbdShift/kbd+kbdF3/kbd (hold kbdShift/kbd down while pressing kbdF3/kbd, then release both keys, in any order)/kbd./p Or eventually: pTo make George eat an apple, press kbdkbdShift/kbd+kbdF3/kbd/kbd (i.e. hold kbdkbdShift/kbd/kbd down while pressing kbdkbdF3/kbd/kbd, then release both keys, in any order)./p
Re: [whatwg] Removal of Ogg is *preposterous*
Dnia 12-12-2007, Śr o godzinie 00:21 -0500, Manuel Amador (Rudd-O) pisze: Look, guys. I don't think I've explained myself well, partly because I've come on too strong. There is no evidence of malice. There's also no evidence of profiteering. There *is* evidence of immorality, if you define spreading falsehoods as immoral (see Ogg is proprietary comment). The rest of the discussion is basically a disagreement on how risky it would be to implement Ogg on browsers. Some of us don't feel it's risky, others feel it's too risky to even consider (I understand -- billions of dollars may be at stake). And both threads are pointless and irrelevant.
Re: [whatwg] Video codec requirements changed
Dnia 12-12-2007, Śr o godzinie 00:11 -0500, Manuel Amador (Rudd-O) pisze: I'd rephrase it as # Has had traction, time and exposure in the market, enough so patent threats should have arisen already. That is, as a study of a troll's lifestyle shows, indefinite.
Re: [whatwg] HTML 5, OGG, competition, civil rights, and persons with disabilities
Dnia 11-12-2007, Wt o godzinie 19:26 -0500, Jeff McAdams pisze: If the text is changed to move away from a free and open solution to something that is going to be encumbered, you better believe I'm going to be up in arms about it, and I will not apologize for it. This change is exactly that sort of change. And you must be... Osama's nephew, right? Oh, that makes me scared. In other words, the fudded turned out to be the fudder. I would much rather Apple not implement HTML5 at all, so I can call Apple out on it in the marketplace, than to let an encumbered technology be ensconced in a standard like HTML5. Why don't you go call out China on Tibet, or USA on Guantanamo? It is much more important and comparably effective.
Re: [whatwg] Video codec requirements changed
Dnia 11-12-2007, Wt o godzinie 18:53 -0500, Manuel Amador (Rudd-O) pisze: Wanna know what happened to the last troll that attacked free software? Ask Darl McBride. Everyone is under the possibility of constant attack from trolls. He was not a patent troll, he was acting for Microsoft and he got his reward for that.
Re: [whatwg] several messages regarding Ogg in HTML5
Dnia 11-12-2007, Wt o godzinie 18:21 -0500, Manuel Amador (Rudd-O) pisze: That's no reason to NOT SUGGEST Ogg Vorbis / Theora. No one here is saying that HTML5 should forbid proprietary codecs -- all we're claiming for is the judicious and well-deserved mention of two free technologies in a document that will be read by MILLIONS of people to come. And you just killed that. You're exaggerating, you are. If Web developers read the specification (or any specification, for that matter), the Web would not look like it does. But they do not; the prefer Dreamweaver, and whatever you have got. Small companies aren't targetted by patent trolls. Only big (really big) companies are. And therefore they're deserving of more protection? Sounds like a racket to me. I am sorry you perceive them this way. Be honest, don't tell me you're sorry because you are not. You're sorry when something personally sad happens to someone you know, not when there's a perfectly valid disagreement on an action you took. Clairvoyant? I don't care much for the content in my own computer, since I encode my things in free formats and using free technology, but I will care when I start playing videos on my computer and it says to me you need codec X, which unfortunately is not available for your Linux computer. If you keep the section you censored, the likelihood of that happening is much, much lower. Not really. Yes, the big players here are fearful and doubtful of the uncertain patent situation surrounding Ogg. That is in fact the entire problem. How curious that the Ogg Vorbis authors never felt that fear, uncertainty and doubt. Perhaps they didn't because they actually did their homework and researched the patent minefield before stepping on one of those mines, instead of saying it can't be done, we're too afraid? Irrelevant, dismissed. Sure. We will just have to wait till we all have 50 megabits/s at home to watch 320x240 videos or something. Maybe we can convince podcast authors to start casting in RIFF WAVE -- I hear it has awesome quality at 8000 Hz mono! Then don't. Read books, it will do you more good. Sadly there's really no such thing as an exhaustive patent search. There's also no such thing as a perfect prophylactic, yet people still use condoms because they're good enough. That does not mean you can force somebody to use them when he is afraid. It'd be fantastic if someone from Xiph pronounced himself on the matter in this forum. But it would not change anything. Tactics change over time. Anyway, it's not our duty to concern ourselves with the *intentions* of the players (though I did shine some light on the issue because it's good to know what the players want). But it is our duty to reflect over the lasting consequences of our actions. This particular action, as already noted, is temporary and it is not meant to have any. Stalling Ogg for a pie-in-the-sky nonexistent solution is not the answer. Ogg is already working in many browsers (both Vorbis and Theora). Despite continued and persistent assertions by bullies (backed on NOTHING but hot air), Ogg is still the best answer. Nobody claimed it is the answer, it is just a workaround. Let me be humorous for a moment. This whole discussion (which is actually NOT representative of the interests of the anti-Ogg bullies) could be summarized as: - Apple: the neighborhood punk is out to get us - Nokia: yeah - MS: indeed - (WHATWG): OK let's just not go out of our house Nobody said that, but You are free to stay at home until we come up with a better solution. For that, we need a codec that is known to not require per-unit or per-distributor licensing, that is compatible with the open source development model, that is of sufficient quality as to be usable, and that is not an additional submarine patent risk for large companies. BMP? MJPEG? WAV? You are being told this question it will take some time to answer this question. The whole point of the change was to make the point that we need something that will not screw you. Ogg isn't a solution, as it won't be implemented by Apple and Microsoft. Honestly, if Apple and Microsoft don't implement Ogg, it will *GUARANTEED* not screw me. If you put it in the spec, they will have to implement it or -- failing that -- there are simple JS-based fallback solutions that are perfectly degradable. So there is NO excuse. It depends on Web authors, and authors rely on what they can see. Otherwise everybody would be using Q for quotations by now. For the record: I don't see a conspiracy. All I see is big interests clearly colluding in the open to further restrict choice for the rest of us. For the record: col·lude –verb (used without object), -lud·ed, -lud·ing. 1. to act together through a secret understanding, esp. with evil or harmful intent. 2. to
Re: [whatwg] Removal of Ogg is *preposterous*
Dnia 11-12-2007, Wt o godzinie 16:37 -0500, Manuel Amador (Rudd-O) pisze: Well, instead of hoping, maybe we can draw more attention to this issue so public pressure helps us do the job. This mailing list is not the best place to draw more attention though. It seems you are wasting your time (and everybody else's). Chris
Re: [whatwg] several messages regarding Ogg in HTML5
Dnia 11-12-2007, Wt o godzinie 23:20 +0100, alex pisze: First, I would like to thank you for the feedback, and I must admit it is a rather sensitive situation, more so then I imagined at first. But because of the nature of submarine patents, I don't quite see how you can actually find a codec that fits the requirements? You can't use an encumbered codec obviously, and the rest is up for grabs by people who misuse legislation for their own benefit? So what else is there (excepting codecs that are outdated in every way that is)? That said, my vote still lies with ogg. Perhaps a unencumbered codec exists that the big vendors would be unwilling to torpedo for some reason? The reason, of course, must be different than the codec in question is clear and safe; it must be an economical one. It would be interesting to see what would happen if the European Commission offered Microsoft a deal: some of the antitrust fine for OGG support in Internet Explorer. Chris
Re: [whatwg] Removal of Ogg is *preposterous*
Dnia 11-12-2007, Wt o godzinie 13:21 -0500, Manuel Amador (Rudd-O) pisze: alternatives -- thank god for Linux). I don't want to experience it all over again, especially since I know that even today, that crapware isn't even gonna be made for Linux, and I'm going to be screwed again. Meaning Totem would be unable to play what? Totem is unable to play Macromedia Flash but Flash is not being discussed here. Chris
Re: [whatwg] whatwg Digest, Vol 33, Issue 90 (Krzysztof ?elechowski)
Dnia 13-12-2007, Cz o godzinie 00:43 +, Sam Kuper pisze: Dear Chris, From the Oxford English Dictionary online (accessed today): initialism: The use of initials; a significative group of initial letters. Now spec. a group of initial letters used as an abbreviation for a name or expression, each letter or part being pronounced separately (contrasted with ACRONYM). You can use an axe as a hammer; that does not make it a hammer though. acronym: A word formed from the initial letters of other words. Hence as v. trans., to convert into an acronym (chiefly pass. and as pa. pple.). This is concordant with my understanding is that in English at least, acronyms and initialisms are abbreviations, but not vice versa. That is, the set of English acronyms is a subset of the set of English abbreviations. Whether or not this is true of Polish, it should not be asserted of English. I admit I am no expert in English. I was afraid presenting my examples in Polish would not make much sense here. A multilingual standard should accommodate the existing practice and terminology of the languages to which it applies; it should not attempt to re-define those practices or terminologies. That is just what I say: Removing ACRONYM because it is a special case for/indistinguishable from ABBR makes HTML English-centric. (If you are not convinced, then consider this analogy: should the HTML spec have insisted that all languages marked up in HTML be written from left to right, using characters called 'a', 'b', 'c', etc?) Sorry to make the point so strongly. Nothing wrong with that; strong points are easier to discuss. All best, Chris
Re: [whatwg] Asynchronous database API feedback
Dnia 10-12-2007, Pn o godzinie 21:22 -0600, Dimitri Glazkov pisze: Guys, I think the point was that it's not unreasonable to have synchronous API. The argument about slow/busy devices is valid, but I still think the developer should have the choice of either going with a simple query/receive calls in their code as opposed to braving complexity of asynchronous API. I fully agree with this point and do believe that if it's a low-hanging fruit, it should be included into the implementation. Allowing the script to wait until the transaction completes would be enough to provide synchronization, wouldn't it? A stubborn programmer can still do it: make a transaction set an event upon completion and make the script loop until that event is set. Upon the theory that the transaction in question is a quickie, it would be quite acceptable, especially if the script engine fiddled with thread priorities a bit. If I am right, it is not such a big issue after all. Chris
Re: [whatwg] Asynchronous database API feedback
Dnia 10-12-2007, Pn o godzinie 16:04 -0800, Dan Mosedale pisze: On Dec 10, 2007, at 12:21 PM, Geoffrey Garen wrote: I'd hate for GMail to mysteriously stop working every couple of days just because of some background process that I had no knowledge of. As a developer, how would you debug such a problem? As a tech support worker, how would you explain it to an end user? +1. Having a bug in a single web-app be able to completely freeze the entire UI of the entire browser (not just that window/tab) seems like a pretty painful user experience, almost to the point of being unacceptable. If an end user ran into this problem very often, I would expect them to blame the browser, and perhaps even switch to a browser which didn't have this problem (i.e. didn't support localStorage). As a user, assuming a synchronous interface with timeouts, I would almost certainly want my browser to enforce a _much_ shorter timeout than 5 seconds... something on the order of 200ms, maybe. Anything that makes repainting stop just feels really bad. Does that mean asynchronous script execution as well? Because if not, it cannot be done, except that the browser implements a script kill timeout, which applies to all scripts, including local database access when it is supported. Best regards, Chris
[whatwg] OT: Re: several messages (trolly-style)
Dnia 07-11-2007, śro o godzinie 15:27 +, Ian Hickson napisał(a): On Tue, 6 Nov 2007, Geoffrey Sneddon wrote: And as far as I can tell, standards other than HTTP have taken this tack too. For example, the document you can access from JavaScript has a referrer property, without the misspelling. I don't think that spelling the attribute noreferer is consistent. It should be noreferrer. Good point, I hadn't considered the DOM attribute. I'll switch to referrer. Hurrah! I hope the Queen will decorate you for performing that heroic act! (sorry, I could not resist...) Chris
Re: [whatwg] Feedback on the ping= attribute (ISSUE-1)
Dnia 02-11-2007, pią o godzinie 22:05 +, Ian Hickson napisał(a): On Sun, 28 Oct 2007, Roy T. Fielding wrote: Aside from all of the other issues, my vote would be to remove the ping attribute from the specification. It is not a desirable feature. [snip] It is not sufficient for accurate user tracking (mandatory in the realm of referral payments) [snip] and is completely redundant to the current features provided by HTTP (cookies and referrer) I don't understand how either cookies or referrers could be used here. Could you elaborate? That's certainly not how tracking is more commonly done today. A client can simply reward the referrer for referring the user to it. What is simpler than that? Cheers, Chris
Re: [whatwg] web-apps: API for text field selections is lacking
Dnia 31-10-2007, śro o godzinie 17:56 +0200, Mikko Rantalainen napisał(a): The section 5.6.2. APIs for the text field selections http://www.whatwg.org/specs/web-apps/current-work/#textFieldSelection defines attributes selectionStart and selectionEnd and method setSelectionRange(). These features are enough to identify the selected data and possibly modify the contents of text field by scripting so that the modification is affected by selected region. There're some problems, though. I represent the following use case: A page contains a textarea. Author adds an additional button for adding a pair of parenthesis around the selected text. The javascript code for this feature (given that e is the text field element) is e.value = e.value.substr(0,e.selectionStart) + ( + e.value.substr(e.selectionStart,e.selectionEnd) + ) + e.value.substr(e.selectionEnd); The problems with the above code: 1) From the UA view, the entire contents of the field has been replaced with a new value and therefore the undo feature of the field cannot represent the fact that the script only added character ( before the selection and character ) after the selection. A method to update only the selected part of the value would be needed to correctly describe the real change to the value to the UA. There is no behavioural difference between removing just the parentheses and reverting to the previous content: the result is the same. 2) There's no good way to set the selection because if the scripts calls setSelectionRange() the UA must set the selection of the text field but it is not required to modify the focus or scrolled part of the text field in any way. In addition, there's no way to query the scroll position of the selection so the script cannot work around this issue either. As a result, setSelectionRange() may be used to set the selection but the selected selection may end up being out of the view from the user point of view. As textarea element may have soft wrapping enabled, the script has no way to even compute the correct line number for the selection start. For the issue 1) I suggest adding a new method replaceSelectionText(in string selection_value) which replaces the section of field's value between offsets selectionStart and selectionEnd with the string selection_value. This replacement should not destroy the text field's undo history - instead it should be treated similarly to paste (text) operation. Because of the platform widgets API limitations, the user agent would have to go through the the same procedure you quoted anyway (or re-implement platform widgets). There is no way to replace a part in the native text box. For the issue 2) I suggest changing the behavior of setSelectionRange() to require that the selection must be made visible to the user. Perhaps something along the lines UA must scroll the text field so that the start of the selection is visible. I do not feel like I would like that. As an alternative, a method such as void focusSelection() could be added so that the script may hint the UA that the selection should be made visible after the script has called setSelectionRange() and replaceSelectionText() multiple times (so that these actions do not repeatedly scroll the text field's viewport). Rather reveal selection, if you please. There is some correlation between focus and visibility but they are not tightly coupled. Best regards, Chris
Re: [whatwg] SQL API + access to tables
Dnia 22-10-2007, pon o godzinie 17:09 -0700, Michaeljohn Clement napisał(a): Křištof Želechovski wrote: Also, if we agreed to that, this would be a workaround for a supposed deficiency of SQL. But the SQL committee does not recognize it as a deficiency; otherwise it would have been fixed by now. No, this is actually fixed for 15 years now. The SQL spec directly addresses this need through the information schema, since SQL92. Every moderately complete SQL implementation I'm aware of also meets this need, either through the means specified by the standard, or by incompatible extensions, as is the general custom. Thanks. In that case let the manufacturers of the incompatible DBMS cater for that (provide a conformant implementation). It has nothing to do with HTML DOM. Chris
Re: [whatwg] hashchange only dispatched in history traversal
Dnia sobota, 11 sierpnia 2007 22:14, Maciej Stachowiak napisał: On Aug 11, 2007, at 10:00 AM, Křištof Želechovski wrote: Originally the name after the hash was a bookmark, not a fragment, because it would be defined on an anchor. I agree that until the new semantic makes it to the common knowledge using the name fragment for the purpose may be surprising for some developers. When was it called a bookmark? I'm pretty sure it has been called a fragment identifier back to at least the late '90s. In the early '90s? And I did not say it was called a bookmark but it was like a bookmark semantically. Chris
Re: [whatwg] My case for Ruby-elements
Dnia niedziela, 12 sierpnia 2007 14:20, Keryx Web napisał: Today, in a private mail Simon Pieters said that HTML 5 will probably get the ruby-elements as well. I had intended to write about this to this list and now simply will ask if this is the case? Personally I have a special use-case. Being a theologian I would like to provide historical documents in an interlinear fashion: Kai ho logos sarx egeneto (Oh, yea, it should be in greek font) and the word flesh became (Literal translation) 2532 3588 3056 4561 1096(Strongs numbers) Imagine this page http://www.studylight.org/isb/bible.cgi?query=joh+1:14it=nasot=bhsnt=na; sr=1 with proper semantic markup! Of course, we theologians are a small minority of mankind, but the CJK-languages will profit from ruby as well, right? Lars Gunther I have just encountered a similar problem, the difference is my problem is vertical. I have a document in two languages; the document has internal structure (not just plain text). My intention is to display this document in two columns with corresponding passages side by side retaining existing markup. I am afraid there is no way to do it because existing markup cannot span table rows. BTW: What do you think about explicit kerning? You can move boxes with a relative position around but the layout depends on their natural positions. I understand this is rather off topic (CSS). Example of application: http://en.wikipedia.org/wiki/Tournament_(graph_theory) (currently viewable with Internet Explorer only) Best regards Chris
Re: [Whatwg] [whatwg] More on postMessage (OT)
Dnia piątek, 20 lipca 2007 04:49, Maciej Stachowiak napisał: I don't think AppleScript is very useful to understanding API design in languages with more conventional syntax. For example, document.write(foobar) is not very well expressed as 'tell document to write foobar', it would be more accurate to say 'write foobar to document'. It is consistent with the original tell paragraph 5 to set word 3 to foobar. I am accustomed to this syntax and I can see nothing weird about it right now. AppleScript rulez :-) Chris
Re: [whatwg] additional key attribute in form field
Dnia piątek, 6 lipca 2007 13:32, Alexander napisał:
Greetings,
i wonder why there's still no a special 'key' attribute for every form
field implemented.
Let's say I have rendered table from query result and one column could be
updateable via text field. And let's say record id field is
uniqueidentifier (not integer). I'd like to write the following:
form ...
!--- Loop query results ---!
input type=text key={id_value_here} name=quantity value=
input type=text key={id_value_here} name=quantity value=
!--- End of loop ---!
/form
and
when submitting the form and checking results on server, I'd like to know
the 'owner' of every quantity field:
!--- loop via quantity fields ---!
if (quantity.key == '----') { ... }
!--- end of loop ---!
Regards,
Alexander.
1. Your code is old-fashioned: the identifier should be used instead of the
name.
2. The identifier should be unique throughout the document so your code will
be ill-formed.
If I understand your intention correctly, you want to submit an entire table
instead of just one record a time; HTML forms clearly were not designed with
that application in mind. I think you would be better off by performing an
internal query on the client side---where you can refer to the form fields by
numeric index rather than by identifier---and reformatting it to JSON before
submission. If this is impossible, you could make a round trip to the server
for each record. My experience shows that it is often the case with current
implementations.
Chris
