Re: [whatwg] Map lang to xml:lang at the parser level

[Anne van Kesteren]

On Thu, 26 Oct 2006 15:22:58 +0200, Henri Sivonen <[EMAIL PROTECTED]> wrote:
I think this proposal is definitely worth considering. Would it have  
any ill effects on scripting compatibility with Appendix C XHTML soup  
served as text/html? In cases like  the DOM  
would not be exactly the same as in legacy browsers. (I am assuming  
here that xml:lang='fr' would disappear in text/html parsing and  
lang='en' would be treated as a meaningless attribute on the  
application/xhtml+xml side.)


Actually, in that case you would have on attribute lang="en" in the XML  
namespace and one attribute xml:lang="fr" in no namespace.


I take in that you mean the text/html case.


Yeah.


That would be possible in browsers whose DOM implementations need to do  
ugly XML-hostile things for text/html anyway. However, other types of  
programs processing HTML5 using XML tools would have to be allowed to  
consider xml:lang in text/html non-conforming and trashable, because  
what you suggest violates basic assumptions that XML processing software  
is supposed to make or even enforce.


How so?


--
Anne van Kesteren

Re: [whatwg] Table integrity and conformance

[Sander Tekelenburg]

At 11:45 -0400 UTC, on 2006-10-26, David Walbert wrote:

> On Oct 26, 2006, at 9:27 AM, Henri Sivonen wrote:

[...]

[axis]

>> I think it should be dropped due to lack of implementations and use
>> after being in HTML 4 for years.

You'd better first find out the cause of that lack of implementation/use.
Maybe that cause has disappeared, or is about to disappear, or can be made to
disappear. Makes no sense to me to throw something potentially quite useful
away without first knowing that.

> It strikes me that the axis and headers attributes could both
> potentially be very useful; but if I were to use them, I'd almost
> certainly generate the table and attributes with server-side script
> (such as PHP), and then there would be no need for the HTML
> attributes since I could generate any desired reports the same way.

I can't follow this. AFAIK axis[*], headers and scope are all intended to
improve accessibility and useability of tabular data; they allow authors to
help user-agents help users to navigate tables. For example, a speech browser
could provide a mechanism to speak the table headers that apply to a cell; a
visual browser could render the table header for a cell when that table
header cell is outside of the viewport (that way we wouldn't even need
scrolling TBODYs anymore), draw lines to the corresponsing table cell headers
of a selected cell, or maybe even hide/grey-out all non-related (header)
cells; Etc.

> They seem to me to provide alternative functionality

Nitpick: HTML provides no functionality. It allows authors to provide useful
descriptions. It's up to the UA to turn that into functionality.

> [...] if the tables aren't generated from a
> database they'd have to be marked up by hand, and that would be a
> tremendous amount of work in which errors could easily be introduced.
> That may explain why the attributes are underused.

I suspect their not being used is more likely due to UAs not supporting them.
(As well as this being one of those non-visual features of the Web... Just
not Flashy enough for most Web publishers ;))


[*] I have to admit I don't understand axis. The HTML 4.01 description of it
is way beyond rocket science to me. So thus far I've only used headers and
scope.


-- 
Sander Tekelenburg, 

Re: [whatwg] Canvas lack of drawString method

[Gervase Markham]

dolphinling wrote:
What if the canvas and span are surrounded by something with 
font-weight:bold? Will the text in the canvas be drawn bold, too?


It's the responsibility of the page designer to make sure the text they 
are measuring is styled the same as the text they want the metrics of.


According to the current API suggestion, the styling of the text in a 
canvas will not be affected by the style of parent elements, but will be 
defined by the style of the pseudo element name passed to the drawText 
function.


Gerv

Re: [whatwg] Table integrity and conformance

[David Walbert]

On Oct 26, 2006, at 9:27 AM, Henri Sivonen wrote:


It might be interesting to have some sort of testing with the "axis"
attribute too, or maybe we should drop it.


I think it should be dropped due to lack of implementations and use  
after being in HTML 4 for years.


It strikes me that the axis and headers attributes could both  
potentially be very useful; but if I were to use them, I'd almost  
certainly generate the table and attributes with server-side script  
(such as PHP), and then there would be no need for the HTML  
attributes since I could generate any desired reports the same way.  
They seem to me to provide alternative functionality for tables in  
lieu of an actual database, but if the tables aren't generated from a  
database they'd have to be marked up by hand, and that would be a  
tremendous amount of work in which errors could easily be introduced.  
That may explain why the attributes are underused.


Is the headers attribute any more widely used than axis? I admit I've  
never used either, but I don't typically generate complex data tables.



David Walbert
LEARN NC
[EMAIL PROTECTED]

Re: [whatwg] Canvas lack of drawString method

[Joao Eiras]

I think mixing CSS and Canvas is a bad idea.
You could develop an application which would implement the canvas APi, and  
be easily programed with ecmascript or java.
Adding this kind of feature would force the implementor to support CSS  
too, at least partially.



Stefan Haustein <[EMAIL PROTECTED]> escreveu:


Hi David,

I think it is very important to be able to determine the rendered size  
of the text. Otherwise, there is no reliable way to make sure things do  
not overlap. Also, some kinds of applications (flash-like effects,  
labels expressing weight or distance, WYSIWYG text editors) may require  
variable font sizes or styles.


What do you think about

context.textStyle = "barchart"; // style by reference

context.textStyle = {  // set style directly
  "font-size": "8px",
  "font-family": "Monaco, monospace"
}

context.drawText(x,y,string); context.getFontAscent();
context.getFontDescent();
context.getFontLeading();
context.getTextWidth(string);

Best regards,
Stefan





David Hyatt wrote:

I think a drawText method would be extremely useful.

Rather than specifying stylistic information explicitly (via a font  
object), I'd use a special parenthetical pseudo-element. thus allowing  
the author to specify the style as for any other element on a page  
something like this...


canvas::canvas-text(barchart)
{
font-size: 8px;
font-family: Monaco, monospace;
}

and then the API would be something like:

drawText(y-coord of baseline, "barchart", myText)

and letter-spacing/word-spacing would work, small-caps would work,  
text-shadow would work, etc. etc.


fitTextToPath might be an interesting API too.

dave
([EMAIL PROTECTED])

On Oct 23, 2006, at 4:07 PM, Stefan Haustein wrote:


Gervase Markham wrote:

Stefan Haustein wrote:

I think drawElement(elem) opens up a whole new can of worms:

- how would an application determine the size of the text box?
- where is the baseline position, needed for exact axis label  
positioning?

- there are probably issues with dynamically calculated text values
- code with lots of cross references to elements will be difficult  
to read
- it needs to be specified whether css properties are inherited from  
the parent element of "elem".
- how much horizontal/vertical space is drawElement permitted to use  
for rendering?
The answer to all of these things is that the browser renders all the  
elements in the page as it would if the  were not supported  
and the alternate content were being used. It then basically  
screenshots the area corresponding to the element (yes, I know this  
needs careful definition) and draws that into the canvas.
I do not see how your statement answers any of my questions except  
from the last one. You can specify some CSS constraints, but how do  
you determine the actual rendering height of a text box with a  
specific width? How do you determine the pixel position of the  
baseline? The cross reference and the dynamic text issues are not  
addressed at all.
Like I said, we want to leverage the browser's deep and complex  
knowledge of text rendering as much as possible, and just take the  
resulting pixel output as it would be shown to the user.
- the implementation in actual browsers may be more complex than it  
seems because of problems with internal data structures for  
rendering hints and implicitly introducing the ability to render the  
same element twice.
- what happens with contained plugins, canvas elements,  
self-references... all this stuff needs to be well-defined
Indeed. I know it's easy to state and there are edge cases. But we  
could put limits on it like e.g. no plugins, no , and still  
have something very useful for rendering text.
So I assume we agree that the element rendering proposal would still  
need significant specification work and is probably much more  
difficult to implement. The element rendering approach may make  
working with bulk text simpler, but this case is already handled quite  
fine by HTML outside the Canvas element. By asking for too much, we  
may end up with nothing at all.


Andrew has provided a clear and simple proposal that can easily be  
implemented without too much consideration of side effects. Putting  
labels on maps, precise text positioning, starwars-like 3d scrolling  
text, labels for game characters or in physics simulations, all the  
stuff that could only be done in a canvas element, is trivial to  
implement with the drawText() approach, but seems much more complex or  
impossible with the element rendering approach.
Moreover, drawElement() would not solve the drawText problem for  
non-browser environments such as Rhino.
How are we anticipating  might be used in a non-browser  
context?
Canvas and some other parts of the spec (e.g. connections) may make a  
lot of sense for Javascript outside of the browser context.  This may  
be outside of the scope of WHATWG, but if we can take out some  
building blocks and use them somewhere else, this is at least 

Re: [whatwg] Table integrity and conformance

[Henri Sivonen]

On Oct 23, 2006, at 21:31, Ian Hickson wrote:

I think it would be good to require table integrity. Specifically I  
think

overlapping cells would be a MUST NOT.


Excellent! Thanks!


It might be interesting to have some sort of testing with the "axis"
attribute too, or maybe we should drop it.


I think it should be dropped due to lack of implementations and use  
after being in HTML 4 for years.


If you do do this, I expect your experience with writing the  
conformance

checker will be a large influence on what the spec end up saying.


Hopefully I can come up with something useful.


On a related note, a potentially interesting feature of a conformance
checker would be to output the document outline so that a human can  
check

that that is correct.


Noted as a feature request for the future. :-)

--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/

Re: [whatwg] Map lang to xml:lang at the parser level

[Henri Sivonen]

On Oct 24, 2006, at 09:39, Anne van Kesteren wrote:

On Mon, 23 Oct 2006 12:52:44 +0200, Henri Sivonen <[EMAIL PROTECTED]>  
wrote:
I think this proposal is definitely worth considering. Would it  
have any ill effects on scripting compatibility with Appendix C  
XHTML soup served as text/html? In cases like xml:lang='fr'> the DOM would not be exactly the same as in legacy  
browsers. (I am assuming here that xml:lang='fr' would disappear  
in text/html parsing and lang='en' would be treated as a  
meaningless attribute on the application/xhtml+xml side.)


Actually, in that case you would have on attribute lang="en" in the  
XML namespace and one attribute xml:lang="fr" in no namespace.


I take in that you mean the text/html case.

That would be possible in browsers whose DOM implementations need to  
do ugly XML-hostile things for text/html anyway. However, other types  
of programs processing HTML5 using XML tools would have to be allowed  
to consider xml:lang in text/html non-conforming and trashable,  
because what you suggest violates basic assumptions that XML  
processing software is supposed to make or even enforce.


--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/