Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A div that looks different in every browser

twitter.com

Post reply on HN
Print view View original

71–80 of 133 posts

Re: A div that looks different in every browser

#71

Post by lisper »

howdydoo wrote: post #67
lisper wrote: post #32

Earlier quoted context omitted.

The code shown on that page actually doesn't work, though the code in the github repo does. And this exposes the problem with the current state of the art: yes, you can probably get flexbox to do what you want [@] if you know how. But if you don't know how, trying to figure it out is still very hard. You should be able to write: stuff or stuff There is really no reason that should not Just Work. (The tag has worked f…

https://codepen.io/anon/pen/NzQQJm This is a gross abuse of html, but if you really want that syntax, you can have it. I can't say I understand all the complaining here. You want to make $200K a year sitting at a desk, but learning flexbox or googling when you need it is too much effort?

Your code breaks the tag: if you try to nest a inside your it doesn't work.

And my complaint is that I believe that computing should be accessible to everyone, and that simple things should not be made difficult just so that an elite guild can command above-market wages to fix problems that they themselves created. I don't believe in broken-windows economics.

Re: A div that looks different in every browser

#72

Post by LukeShu »

bla2 wrote: post #55
kevingadd wrote: post #33

Earlier quoted context omitted.

"Chrome's" rendering in many cases is going to be whatever hardware accelerated stack (probably Skia + your platform's particular hardware API) is rasterizing the page. Headless rendering as found in a page scraper bot is more likely to be using software rasterization and might be using an entirely different API. Chrome has a few command line flags that can push everything through different rendering paths and you ca…

Blink (the HTML engine) is still going to push the same drawing commands to all the backends. Winding rule order stuff might be different if a backend is buggy, but things like this shouldn't be different.

I wouldn't be surprised at all if there's a drawing command that's having a negative number passed to it in a place where it doesn't expect negatives. I wouldn't be too surprised if different backends handled this "undefined behavior" differently.

Re: A div that looks different in every browser

#74

Post by gsnedders »

systoll wrote: post #22

Here's an animated version with some transparency https://codepen.io/anon/pen/PaMVYX?editors=0100 The root issue is that the browsers are being asked to draw a line that's 100px in from the edge of a 100px box -- it's an impossible task, so there's no perfect solution. This CSS test suite http://test.csswg.org/suites/css-ui-3_dev/nightly-unstable/x... suggests that browsers should treat it as though it were the large…

The negative value case is:

> Negative values must cause the outline to shrink into the border box. Both the height and the width of outside of the shape drawn by the outline should not become smaller than twice the computed value of the outline-width property, to make sure that an outline can be rendered even with large negative values. User Agents should apply this constraint independently in each dimension. If the outline is drawn as multiple disconnected shapes, this constraint applies to each shape separately.

There's a lot of RFC 2119 SHOULD there, unfortunately.

Re: A div that looks different in every browser

#75

Post by gsnedders »

Buge wrote: post #45
jayd16 wrote: post #31

Earlier quoted context omitted.

This isn't really a spec thing. Its more a manifestation of undefined behavior. Even c++ compilers have undefined behavior.

But in c++ when there's undefined behavior, the spec specifically says there's undefined behavior. It doesn't sound like the spec is specifically saying there's undefined behavior in this case.

I'm not 100% on how explicit it is (IIRC, most of this is given by setting constraints on the rendering), but it's certainly deliberate that this is unspecified.

Re: A div that looks different in every browser

#76

Post by gsnedders »

LukeShu wrote: post #72
bla2 wrote: post #55

Earlier quoted context omitted.

Blink (the HTML engine) is still going to push the same drawing commands to all the backends. Winding rule order stuff might be different if a backend is buggy, but things like this shouldn't be different.

I wouldn't be surprised at all if there's a drawing command that's having a negative number passed to it in a place where it doesn't expect negatives. I wouldn't be too surprised if different backends handled this "undefined behavior" differently.

Nah, this will all be handled within Blink. The drawing command will literally be told to draw polygons in the specific places in the coordinate space.

Re: A div that looks different in every browser

#77

Post by gsnedders »

JBiserkov wrote: post #4

See also this https://mobile.twitter.com/frivoal/status/101544179390147788...

Note that Florian is the editor of CSS UI, which defines the outline properties, where all this unspecified behaviour exists (mostly because browser vendors don't really care enough to make outline interoperable).

Re: A div that looks different in every browser

#78

Post by sonnyblarney »

shawn wrote: post #62
sonnyblarney wrote: post #58

Earlier quoted context omitted.

" I know this isn't actually true " It's true. A confluence of vague definitions, poor implementations, bad documentation ... and this is the web we have. It's the tip of the iceberg, and the painful life of anyone doing html5 work, it's 'not fun' for anyone who's been exposed to regular programming because the problems you spend your day solving mostly should not be problems to begin with.

This is what us older people would like to believe. Meanwhile the young webdevs are having a blast ignoring us and building the apps of the future.

My experience is that young web-devs don't even know the dystopian matrix they live in, and when they discover 'regular programming', in many ways their perspective changes. Both web and regular dev have their faults but the the King of Byzantium is HTML5.

Re: A div that looks different in every browser

#79

Post by evan_ »

lisper wrote: post #32
evan_ wrote: post #29

Earlier quoted context omitted.

Flex box https://philipwalton.github.io/solved-by-flexbox/demos/verti...

The code shown on that page actually doesn't work, though the code in the github repo does. And this exposes the problem with the current state of the art: yes, you can probably get flexbox to do what you want [@] if you know how. But if you don't know how, trying to figure it out is still very hard. You should be able to write: stuff or stuff There is really no reason that should not Just Work. (The tag has worked f…

So should there also be a and a and a and and and and and...?

If you want to lower left align you set align-items and justify-content to flex-end and flex-start. For upper right, flip those. (if you’ve changed flex-direction those will need to shuffle around.)

I seriously don't understand why having a different tag for every possible alignment would be somehow easier or more discoverable than just using css rules. Novices are going to have to be looking stuff up either way- I get the concern about discoverability but I strongly doubt anyone is just typing tags to see what works.

Post reply on HN