15:06
<wayneca>
Since the page I used for an example is a work in progress, I decided that I would discuss here what I am doing with it. It is supposed to be as complete a list as possible of every tag and attribute that has existed in the history of HTML and the W3. I am finding that with the previous versions of the DTD (the SGML based ones through 4.01) it is easy to determine what attributes were given to each element. In the Living Standard version, being removed from the SGML requirement for things to be so specific, the specification is written very differently. It has become difficult to determine exactly which attributes should be listed with a given element, and which attributes from the past are no longer relevant. I am also having difficulty with finding a list of the onEvent attributes (such as onMouseDown) in the HTML 5 specification. Is there a concise list?
15:09
<wayneca>
It also seems like the Global Attributes contain members that are not all useful on every element that has them. Is there a way to differentiate between them as they pertain to a given element?
15:20
<wayneca>
Also, I feel I should make a distinction in what I said in my first post. I am not saying Firefox is right and everyone else is wrong. I'm saying that there needs to be an agreed upon definition of proper rendering that all browsers should adhere to if they want to render web pages correctly. Then all web pages would look the same in every browser no matter what platform or browser the user has. Of course, there are limits, such as different screen size and resolutions. The authors of the web pages would have to ensure that they code the pages in such a way that it accommodates as many users as possible, realizing that there will be some users who simply won't see the page as intended.
15:31
<wayneca>
While this site is still basically offline while I develop the pages, I have made that page available so those that need to or are interested can see my progress. I have also now included my Notes page (https://wayneca.neocities.org/WebDesign/Notes.html) so you can see the remarks I have made concerning the effort. This is also a work in progress as I have just begun this work over the past week.
15:47
<annevk>
wayneca: FWIW, although we do define how HTML maps to CSS in the Rendering section of the HTML Standard, how those CSS rules translate into a picture on your screen is not something the WHATWG works on (W3C's CSS WG does), though many here have some expertise in it. (And some a lot.)
15:52
<wayneca>
wayneca: FWIW, although we do define how HTML maps to CSS in the Rendering section of the HTML Standard, how those CSS rules translate into a picture on your screen is not something the WHATWG works on (W3C's CSS WG does), though many here have some expertise in it. (And some a lot.)
Thanks for your input. I realize that the focus of the WHATWG may not be the same as the W3C, but this is the only forum I know of that has so many browser developers in one place. I am reaching out to the browser developers because this is something that has not really been addressed in the history of the W3 that I know of.
15:55
<Luca Casonato>
All three major browser vendors are members of W3C. How exactly a page is rendered (how flex works, how tables should flow, etc) is all specified by the CSSWG. You can see the members here: https://www.w3.org/Style/CSS/members.en.php3
15:56
<wayneca>
Also, if it was all so straight-forward as the specification defines it, different browsers would not render the pages so differently. I believe that this can and should be remedied by the browser developers coming together and defining the specifics of what a rendered page should look like.
15:57
<Luca Casonato>
Also, if it was all so straight-forward as the specification defines it, different browsers would not render the pages so differently. I believe that this can and should be remedied by the browser developers coming together and defining the specifics of what a rendered page should look like.
The problem here is not specifications. They exist. The problem is that there are three different engines with different bugs. If you see rendering differences, then these are bugs in individual engines.
15:57
<Andreu Botella>
I don't know about how things are rendered on your system, but in mine the differences between Firefox and Chrome are because I don't have Tahoma installed in my system, and different browsers use different fallback fonts. So that's also something that you can't expect browsers to agree on.
15:58
<wayneca>
I see. So it's a matter of finding and squashing the bugs.
15:59
<Luca Casonato>
I see. So it's a matter of finding and squashing the bugs.
We have shared test suites to tackle this, but they do not have 100% coverage. And even with 100% perfect coverage, the actual implementation of the specs definitly follows the 80:20 rule. The last 20% of issues is just as hard as the first 80%.
15:59
<wayneca>
I don't know about how things are rendered on your system, but in mine the differences between Firefox and Chrome are because I don't have Tahoma installed in my system, and different browsers use different fallback fonts. So that's also something that you can't expect browsers to agree on.
Well, I know that this is why you can specify multiple fonts to fall back on. I haven't done it yet, but that's because I am still trying to get all of the data in. Once that is done I can worry about fallback fonts. That was my thinking. I guess I should remedy that now though.
16:00
<Luca Casonato>
https://github.com/web-platform-tests/wpt for example
16:00
<Luca Casonato>
Most of the rendering tests are in https://github.com/web-platform-tests/wpt/tree/master/css
16:01
<wayneca>
https://github.com/web-platform-tests/wpt for example
Thanks for the info. I will read at least some of that when I have the time.
16:02
<wayneca>
What would any of you say are the most common sans-serif fonts? Would Monaco be one?
16:05
<wayneca>
I have already specified sans-serif as a family in my font-family property. Is that not enough for a system to use whatever is available on a system that doesn't have Tahoma?
16:07
<Alan Stearns>
That is enough, and the text will render in whatever font the browser chooses.
16:08
<wayneca>
That is what I thought too, but I updated the files to include Verdana, Arial, Helvetica also.
16:10
<Alan Stearns>
That’s usually not necessary (unless you really have a preference for those fonts). Picking your first desired font, then having a generic family fallback is fine
16:11
<wayneca>
OK. I had thought that was the case, but when Andreu Botella stated that they didn't have Tahoma installed on their computer it made me rethink.
16:13
<Andreu Botella>
Tahoma, Verdana, Arial, Helvetica are all fonts that come with Windows systems and don't tend to come with, say, Linux
16:14
<Andreu Botella>
there are fonts with the same metrics that might come in Linux systems, but they don't have those names
16:15
<wayneca>
That is why I initially included sans-serif in the family list: font-family:Tahoma, sans-serif;
16:16
<wayneca>
I thought I understood that this would allow a system that didn't have Tahoma to fall back on whatever sans-serif font it has.
16:17
<Andreu Botella>
if there are multiple, browsers are free to choose one, and different browsers might choose differently
16:18
<wayneca>
Well, I really don't have the means to see what every sans-serif font looks like, so I try to allow the user to determine their own preference when possible.
16:18
<wayneca>
I'm not certain that my pages look as good with other fonts though.
19:23
<TabAtkins>
What's the syntax in the HTML source for indicating that a heading has multiple IDs?
19:23
<TabAtkins>
Trying to track it down but it doesn't show up very often :(
19:23
<TabAtkins>
Domenic annevk ?
19:24
<Domenic>
TabAtkins: usually something hacky like <span id="..."> inside the heading... let me see if I can find an example.
19:24
<Domenic>
Yeah <h5 id="image-map-processing-model"><span id="processing-model"></span>Processing model</h5>
19:26
<TabAtkins>
danke
23:47
<Lorenz>
Hi, I hope this is a good place for my question. I tried to figure out why only link and script tags support SRI. I had a chat with Eric Lawrence, and he told me that there are some theoretical plans to support it (see https://www.w3.org/TR/SRI/#verification-of-html-document-subresources). Does anyone know what the current status of this is? Eric told me that potentially Mike West might have some insights, but maybe also someone else knows anything about it.